Re[2]: минусы Ruby
От: VladD2 Российская Империя www.nemerle.org
Дата: 28.05.06 15:49
Оценка: 3 (1) +1 -6 :))) :)
Здравствуйте, eao197, Вы писали:

Прочтя этот ответ я понял, осознал главную причину по которой нельзя использовать Руби в серьезных проектах. "это же OpenSource со всеми вытекающими" А вытекающие кривизна.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: минусы Ruby
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 28.05.06 13:03
Оценка: 49 (7) +1 :))
Здравствуйте, Курилка, Вы писали:

К>Собственно хотел предложить для прочтения (и обсуждения тоже) статью 5 things I hate about Ruby

К>Особенно не положительным 4-й пункт кажется: навязываемый "Ruby Way", который ещё и не имеет однозначной трактовки.

Сначала по пунктам:

1.Ruby is slow.

Да, медленный. Но Erlang, говорят, так же не быстр, тем не менее, препятствием это не является. Нужно выбирать области, в которых скорость Ruby не будет сказываться печатльным образом. Писать числодробилки на Ruby (пока) -- это демонстрировать отсутствие здравого смысла. Зато для некоторых задач производительность Ruby вообще не как не будет сказываться на скорости, т.к. будут наличиствовать более тормознутые компоненты. Вот примеры из собственного опыта использования Ruby:
a) обработка больших (сотни мегабайт, иногда гигабайты) объемов логов с извлечением из них информации с сохранением в РСУБД. Скорость работы дисковой подсистемы и скорость сохранения информации в БД (со включенными индексами) будет настолько медленнее скорости работы самого Ruby кода, что переписывание данныой задачи даже на C++ не даст прироста производительности и в несколько процентов.
b) создание управляющих скриптов для проведения каких-нибудь сложных действий при помощи других утилит. Например, использование svnadmin для получения dump-ов репозиториев, из архивация, копирование в специальные архивные каталоги и пр. Либо переодический поиск мусора, оставляемого приложением (устаревшие log-файлы, забытые tmp-файл b пр.) с последующей архивацией и/или удалением. Работа внешних утилит будет занимать практически 100% всего времени работы подобного скрипта.
c) обработка C++ исходников с целью поиска #include-зависимостей (в Mxx_ru используется написанный на Ruby вариант). Парсинг тысяч исходных файлов объемом в десятки килобайт так же серьезно нагружает дисковую подсистему. И при этом скорость Ruby скрипта все равно оказывается нормальной для повседневного использования.

Так же можно почитать различные высказывания о скорости работы Ruby-приложений в Web (на основе Ruby-On-Rails) к примеру: Scaling Rails или соотвествующую главу в Agile Web Development with Rails.

2. Ruby's development process is slow.

Смотря с чем сравнивать. Если с C#, то медленный. Если с Java, D или, прости господи, Perl 6, то нормальная скорость. Тем более, что это OpenSource проект. Выпускающий весьма стабильные релизы. Так что, можно оставить данное высказывание на совести автора.

3. Ruby's "official" documentation is sparse and, in some cases, nonexistent.

Да, документация по Core API и стандартным бибиотекам с ruby-doc.org действительно не полная. Но, блин, это же OpenSource со всеми вытекающими. Не хватает чего-нибудь, так разберись и допиши. И себе польза, и окружающим.

К тому же не нужно забывать, что практически вся стандартная библиотека Ruby доступна в Ruby-исходниках, а остальная часть -- в C исходниках. Обратиться к ним за разьяснение каких-то непонятных вопрос дело нескольких минут.

Ну и кроме сгенерированной rdoc-ом документации по API есть еще и книги по Ruby. Например, мне хватило первого издания Programming Ruby (которое доступно в on-line, и входит в дистрибутив OneClickRubyInstaller). А второе издание вообще покрыло столько вопросов, сколько мне на практике и не нужно. Кроме этой книги есть еще:
Ruby Developers Guide
The Ruby Way
Ruby for Rails: Ruby Techniques for Rails Developers
Agile Web Development with Rails
Так что, если не жалеть денег на приобретение книг (либо научившись пользоваться файлообменными сетями), то информации о Ruby совсем не мало.

4. Screw the Ruby Way, sometimes I just want to get things done.

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

5. Ruby has shitty XML support.

Бред в том смысле, что язык должен поддерживать XML. Пусть этим, например, Scala занимается, она для этого проектировалась. Поддержка XML должна содержатся в библиотеках. Такие библиотеки есть. Тот же REXML, который входит в стандартную библиотеку Ruby. И опять нужно вспомнить, что Ruby и REXML -- это OpenSource проекты. Если что-то не нравится, то жаловаться не конструктивно. Нет богатого дяденьки (в лице Novell, Sun или Microsoft), который будет вкладывать деньги в сопровождение. Просто так ничего не возникнет. Нужно либо самому доводить проблемную библиотеку до ума, либо помогать ее разработчикам.



Резюмируя: первый и третий пункт действительно содержат верную информацию, но с демонстрацией не понимания природы вещей (в частности факта OpenSource природы Ruby и его библиотек). Пятый пункт спорен. Четвертый -- маразм, не заслуживающий внимания.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re: минусы Ruby
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 29.05.06 12:54
Оценка: 49 (5) :))
Здравствуйте, Курилка, Вы писали:

К>Собственно хотел предложить для прочтения (и обсуждения тоже) статью 5 things I hate about Ruby


Собственно, со статьей-то уже все понятно. Но, если есть желание, то можно пообсуждать минусы Руби.

Имхо, их можно разделить на три категории.

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

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

Во-вторых, это неочевидность связей по данным. В коде можно увидеть фрагмент:
# Determining dependencies list for all who will link this DLL.
dll_requirements = make_dll_requirements(
  dll_file, dll_info, link_lists, target )

target.mxx_add_required_libs( dll_requirements.libs )
target.mxx_add_required_lib_paths( dll_requirements.lib_paths )

Но понять, какого типа объект возвращается методом make_dll_requirements, что возвращают методы libs и lib_paths с ходу невозможно. Нужно делать браузинг по исходникам, чтобы докапаться до сути. Smalltalk в этом плане выигрывает у Ruby наличием развитых IDE с мощными браузерами классов.
Справидливости ради хочу заметить, что у данного минуса есть своя положительная сторона: часто просматривая код лучше понимаешь поведение программы.

2. Особенности текущей ситации с Ruby.

Ruby пришел из Японии и поэтому он больше известен на Востоке (говорят, по популярности там он давно оставил позади Perl с Python-ом). Но на Западе, да и у нас, Ruby только приобретает известность. Соотвественно, информации о нем меньше, меньше готовых Ruby-программистов.

На данный момент Ruby не обладает высокой скоростью. Во-первых, это связано с самой динамической природой языка. Во-вторых, пока нет виртуальных машин и интерпретаторов, способных обеспечить высокую скорость. Но, усилия в этом направлении в Ruby 1.9 и YARV позволяют надеятся, что ситуация переменится. Чем больше людей будут пользоваться Ruby, тем больше внимания будет уделяться данной проблеме и тем больше шансов, что она будет успешно преодолена.

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

3. Особенности самого языка.

Мне кажется, что у Ruby ситуация похожая на C++: сильные стороны языка одновременно являются и его недостатками (косвенным образом это подтвержается еще и тем, что VladD2 ругает Ruby не меньше, чем C++). Так, в Ruby нет единственного правильного способа сделать что-нибудь, как правило, существует несколько равноценных путей из которых программист должен сам выбирать. Например, как можно вызвать метод у объекта, ссылка на который может быть нулевой?
if nil != obj
  obj.call_something
end
[rb]
А можно и так:
[rb]
obj.call_something if obj

Или как пройтись по всем элементам какого-то контейнера (например, массива)?
i = 0
while i != a.size
  do_something a[i]
  i += 1
end

или
for item in a
  do_something item
end

или
a.each { |item| do_something item }

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

Другая особенность Ruby в том, что он только на первый взгляд кажестя простым языком. На самом деле он не прост. Мелкие фокусы могут возникать на каждом шагу. Например:
i = 0; puts i ? 'non zero' : 'zero'

Что будет отображено? И почему?
Другая сторона сложности языка -- это возможности метапрограммирования. С одной стороны, для успешного применения метапрограммирования необходимо понимать внутреннее устройство Ruby классов (оношения между объектами, классами и метаклассами). Кстати, хорошо это дело освещается во втором издании Programming Ruby и в статье Seeing Metaclasses Clearly.

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

Две вышеописанные особенности Ruby делают этот язык для меня похожим на C++. Как следствие, Ruby хорошо подойдет небольшим командам опытных разработчиков или даже для индивидуального использования. В пользу этого так же играет и описанная в самом начале сложность с определением связи по данными в программе на динамическом языке. В маленькой, сплоченной команде отслеживать зависимости в коде будет проще. Да и ориентироваться в чужом коде в таких условиях так же гораздо удобнее.

А посему можно сказать, что минусом Ruby является то, что он вряд ли будет языком для больших команд. Хотя еще вопрос, считать ли это минусом


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[9]: минусы Ruby
От: Mamut Швеция http://dmitriid.com
Дата: 03.06.06 06:57
Оценка: 29 (2) +1 :))) :)
VD>>>Ага. Оно и видно. Один пользуется, а рассуждений о Руби как будто на нем все пишут.

M>>Справедливости ради замечу, что интерес к Руби в интернете растет.


VD>Справедливости ради, тоже позволю себе заметить, что это баян. Причем место ему в юморе. Мы же это воде обсуждали.


Ну, на РСДН есть как минимум четыре человека, которые, как я понимаю, Руби пользуются. Ну, ладно, себя я пока не буду включать Тогда три. Это уже сила и мы имеем право на свои священные войны
... << RSDN@Home 1.2.0 alpha rev. 647>>


dmitriid.comGitHubLinkedIn
Re[4]: минусы Ruby
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.06.06 15:00
Оценка: 9 (2) -1 :))) :)
Здравствуйте, eao197, Вы писали:

E>Про те два пункта, где он был прав я и сказал в своем резюме. Пункт 4-й (про Ruby Way) -- это полный маразм. Поддержка XML-я непосредственно в язык -- это из той же оперы.


А по-моему, насколько я его понял, далеко не маразм.

VD>>На счет того, что я ругаю Руби — это не правда. Я ругаю необоснованную его рекламу.


E>О как! Т.е. отсутствие громких флеймов под заголовками "Ruby рулит"


Неправду то не надо говорить. Громких криков о Руби лично от одного тебя здесь выше крышы, а флэймов нет толко потому, что Руби этот интересует основную аудиторию в основном теоритически. Вот когда затрагивается С++, то варьеров на белых конях появляется намного больше.

E> и "Ruby -- профанация не пройдет" -- это и есть необоснованная реклама. Особенно, если сравнивать с другими .NET-языками.


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

E>Ruby предназначен для быстрой разработки, а не для быстрого исполнения.


Не... Вот это огромное заблуждение. C# с Решарпером, вот это средство быстрой разработки. А Руби с VIM-ом это средсво для гонок на черепаших бегах. Никакой супер язык не даст серьезного ускорения процесса разработки если для него нет RAD-средств. Ускорение видно, только если сравнивать его с ведущимся такими же доисторическими средствами процессом программирования на С++.

E> Сама его природа (открытые типы, например) определяет, что он не сможет в принципе достигать скорости C++. А раз так, зачем корячиться.


Ага. Хреновая природа. И она же не позволят сделать полноценную поддержку IDE. Ведь по сути чтобы вычислить типы нужно выполнить программу.

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


Это чистой воды лож. Руби н любых задачах последний по скорости даже по сравнению с Питоном. А уж компилируемые языки даже сравнивать не смешно. Ну, а то, что на руби можно запустить программу написанную на С++ не делает чести самому Руби.

E> (ссылки сейчас искать некогда, но в Философии была тема про скорость импорта в БД данных из гигабайтных логов программой, написанной на F#; в Средствах разработки dmz сравнивал скорость парсинга логов на Python и Perl, туда же было добавлено сравнение с Ruby; в исходниках лежит мой проект svn-dumper-loader -- там svn dump на 160Mb репозитории работает минуту, а затем две минуты dump-файл архивируется bzip2, при таких показателях сам Ruby скрипт просто летает).


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

VD>>отсуствие полноценной IDE (комплит, рефакториг, ...),


E>Да есть IDE для Ruby, как open-source (FreeRDE, Mongrel, RDT), так и коммерческие (Komodo).

E>Более того, Rubyist-ов совсем это не парит. Большинство используют VIM, emacs и TextMate (под MacOS), не испытывая при этом никаких сожалений.

Это означает, что IDE нет. Все эти "IDE" по возможностям не сильно превосходят Сцинтилу. Руби же принципиаьно не может иметь полноценной поддержки IDE, так как динамическая природа языка практически гарантирует невозможность вычисления типов до зпуска программы. А типы — это главное, что требуется для всех средств автоматизации. В Питоне вот пробуют вычислять типы путем их вывода, но сделать это в специально не спроектинованном для этого языке очень не просто. Да и результат будет похож на очень убогий Немерле.

VD>>отсутствие статической типизации,


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


Ага. Почти все проблемы языка растут отсюда.

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


Это недостаток личо для меня основной. А то что этот недостаток ставит крест не на одном Руби, а на целом классе языков, так это не мои проблемы.

VD>>черезмерная экономия на длинне идентификаторов в стандартной библиотеке,


E>Вот уж не замечал.


А что ты вообще замечал? Ты пользушся средствами разработки на уровне 70-ых готов прошлого века. От того тебя радует даже минимум. Ну, по думашь там to_s что-то назвали? Фигня... Сделем из своей головы огромный хэш-мап и будет ассоциировать эти to_s в tt_string. За то каждая строчка на 5-7 симвлово короче. Это же главное! Не правда ли?

E> Вот список методов, начинающихся на букву A из Core Library:

...
Даже в приведенном тобой списке (хотя он намерянно опускает особо цинично короткие названия) есть изумительные варианты. То что ты считашь, что так и должно быть — это не более чем твои привычки. А я уже привык к полноценным именам. Я конечно понимаю, что библиотек в Руби не так много и можно натринироваться и запомнить их основную часть, а чуть что лажить в документацию (про которую ты и сам сказал "...что же вы хотите? Это же ОпенСорс..."), но я так жить не хочу. Я хочу полноценный комплит-ворд и сами за себя говорящие имена методов. Так же хочу, чтобы кроме имен были еще хинты которые более развернуто говорят о том, что делают классы и их члены.

E>Какие из них ты считаешь черезмерно сокращенными?


Большей частью те что остались за кадром (видмо намеренно). Например, to_s. Но и из приведенных примеров перлов можно недергать не мало. Например, ajd_to_jd меня очень радует. Видимо метод преобразует Албанского Джона Дудаева в еще кого-то странного.

E>Ну и не нужно забывать, что в мире динамических языков процветают принципы code less и don't repeat yourself. Поэтому идентификаторы to_i, to_f, to_s, to_str, to_sym -- являются нормальными и удобными в использовании.


Мир маргиналов — вот как называется описанный тобой мир. Однобуквеные сокращения в публичном интерфейсе для меня сродни немытому бомжу посередине станции метро.

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


E>Это к пункту про статическую типизацию.


Нет. Это к пункту о маргиналах. Такое же наплевательское отношение к пользовтелям языка. К статической типизации это отношения не имеет.

VD>>текстуальность метарасширений.


E>По мне, так эта текстуальность гораздо нагляднее


Кто бы сомневался. По тебе так все зашибись. Чем маргинальнее, тем лучше.

E> птичьего языка макросов из твоего любимого языка.


Что является птичьим языком еще большой вопрос.

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


Не, не. Не даже "отладочными печатями", а исключительно ими. Причем никакого статического контроля. А "отладочными печатями" можно отлаживать почти все что угодно. Вот только не хочется жить в этой смеси маргинальных подходов с доисторическим материализмом.

VD>>А сам язык как раз очень ничего.


E>Да уж... Язык-то как раз полезен теми вещами, которые ты только что здесь раскритиковал.


Отндь. В Руби хватает красивых и полезных решений. Но ты почему-то любишь в нем откровенно грязные хаки и халтуру. Мне вот в Руби понравились блоки код, континюэшоны, отсуствие стэйтментов. Конечно есть и другие языке с тем же самым, но и в Руби оно есть. Причем реализовано довольно гладко.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[18]: минусы Ruby
От: Kluev  
Дата: 05.06.06 08:11
Оценка: 1 (1) +1 :))) :))
Здравствуйте, FR, Вы писали:

FR>Здравствуйте, VladD2, Вы писали:


VD>>Хм,

VD>>
VD>>prefix + HexStrToIntStr(hexStr) + sufix
VD>>

VD>>мене понятен чем
VD>>
VD>>m[1] + m[2].to_i(16).to_s + m[3]
VD>>


VD>>Во истину о вкусах не спорят.


Причем тут вкусы? to_i(16).to_s — понятно любому сишнику без кометариев. Хинт atoi и itoa. Только вместо a — s, и первые части (a)toi и (i)toa поскипаны т.к. это не функции, а методы обьектов. Вообщем to_i и to_s — это clear as mud. А вот что такое HexStrToIntStr — от этого действительно можно впасть в ступор. Типично микросовтовский подход, не хватает только добавить булевый параметр, если true то Hex->Int, если false то Int->Hex.
Re[7]: минусы Ruby
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 01.06.06 18:50
Оценка: +5 -1
Здравствуйте, VladD2, Вы писали:

VD>Ага. Оно и видно. Один пользуется, а рассуждений о Руби как будто на нем все пишут.


Руби то хоть один пользуется. А вот кто пользуется Nemerle вообще не понятно, а разговоров

E>>Ты хоть понял о чем сказал?

E>>Попробуй внятно объяснить, в чем будет преимущество Nemerle или C# при решении задачи svn-dumper-loader-а
Автор: eao197
Дата: 29.05.06
.


VD>Заметил, что к твоему сообщению ни одной оценки? Это потому что там огромное описание и написано на чем-то что далеко от народа.


VD>Мне вот тоже влом тратить пол часа, чтобы прочесть все это ради спортивного интереса.


Уже есть одна. И, если бы ты прочел хотя бы пару первых абзацев, то понял бы о чем речь. Хотя ты можешь и не знать, что репозиторий svn 1.1 на базе bdb не открывается svn 1.3 и репозиторию требуется конвертация (самым простым вариантом которого является dump/load).

А если бы прочитал, то наверняка бы предложил несколько более удобных способов реализации того же самого на Nemerle или C#. Еще бы, это же такие языки, которые любую задачу позволяют решать в лет

E>>Я бы сказал, что это не ставит крест на целой группе языков.


VD>Ну, можешь поглядеть каков интерес к вашим Руби и Питонам на этом сайте.


На этом сайте явное доминирование .NET и C++, даже Java (по крайней мере в Средствах разработки, Исходниках и Философии) в глубоком заднем проходе. Так что RSDN не показатель востребованности Руби, Перла или Питона.

VD>Из с криптов массовое распространение получил ЯваСкрипт и тот потому что в броузеры вмонтирован и по факту является единственным средством их расширения.


Да уж, это вообще но комментс.
Хотя, все же спрошу: JavaScript где-нибудь как самостоятельный язык программирования используется (без браузера и не как встроенный язык)?

E>> Отнюдь. Скорее, это привлечет к ним внимание тех, кто не считает тебя пророком и всезнайкой. А уж самим языкам от твоего мнения о них ни тепло ни холодно.


VD>А ты себя кем считашь рассказывая здесь в одиночестве сказки о Руби? Или мы только мою личность обсуждаем?


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

VD>Вопрос настолько неразумен, что я даже теряюсь. ToString полностью описывает смысл метода. А вот что значит to_s можно толко запомнить. Запомнить один to_s может и можно. Но таких вот сокращений в Руби пруд пруди.


VD>В общем, я не понимаю о чем спор. Ты думшь я передумаю от того что ты скажешь "а мне нравится"? Нет. Я высказал свое мнение. Высказал его по твоей просьбе. Что ты еще хочешь?


Ничего. Просто говорю, что если для тебя привычным и логичным является ToString, то точно так же для других привычным и логичным является to_s. Поскольку предназначены для одного и того же и имена логически вычисляются: to (действие) + имя типа. В Ruby имя типа обозначается короче. Вот и вся разница.

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

E>>Тебе бы было понятнее, если бы он назывался ConvertAstronomicalJulianDayNumberToJulianDayNumber?


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


E>> Тогда давай ты сразу, с ходу, без обращения к справочникам объяснишь, чем отличается Astronomical Juluan Day от Julian Day.


VD>А зачем? Главное, что я понял, что деалает метод. А уж подробности исчисления дат меня не интересует. Мне достаточно того, что мне он на фиг не упал. А вот если бы он был мне нужен, то я знал бы эти подробности.


Так вот, я так же не знаю, что такое Astronomical Julian Day, поэтому метод ajd_to_jd мне на фиг не упал. А если бы он был мне нужен, то имя ajd_to_jd было бы для меня абсолютно понятным.

VD>Рад что тебе весело. Меня вообще радует когда я кого-то радую. Будь то попутчик в лифте или представитель одного из направлений нетрадиционного секса с компьютерами.


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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[5]: минусы Ruby
От: Valodzka Беларусь  
Дата: 29.05.06 19:46
Оценка: 1 (1) +4
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Андрей Хропов, Вы писали:


АХ>>Здравствуйте, VladD2, Вы писали:


VD>>>Прочтя этот ответ я понял, осознал главную причину по которой нельзя использовать Руби в серьезных проектах. "это же OpenSource со всеми вытекающими" А вытекающие кривизна.

АХ>>Я думаю "За и против OpenSource" — это отдельная СВ. Давай здесь только про Руби.

АХ>>P.S. Nemerle — это тоже Open source .


VD>Я иногда балдею с узости взглядов царящих на РСДН. Я уже давно замечаю, что если после шутски не вставить слово "лопата", то никто не засмеется. И давно замечаю, что нужно разжевывать и в рот закладывать.


Если это замечает только один человек, то скорее всего с его юмором что-то не то...
Не перебивайте меня, когда я вас перебиваю
Re[20]: минусы Ruby
От: Kluev  
Дата: 05.06.06 19:56
Оценка: :))) :)
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Kluev, Вы писали:


K>>Причем тут вкусы? to_i(16).to_s — понятно любому сишнику без кометариев. Хинт atoi и itoa. Только вместо a — s, и первые части (a)toi и (i)toa поскипаны т.к. это не функции, а методы обьектов. Вообщем to_i и to_s — это clear as mud. А вот что такое HexStrToIntStr — от этого действительно можно впасть в ступор. Типично микросовтовский подход, не хватает только добавить булевый параметр, если true то Hex->Int, если false то Int->Hex.


VD>Финиш... сполз под стол... жувот болит от смеха. Если это не намеренная клаунада, то разговор нужно закрывать, так как играть в дурдом это уже перебор.


Клоунада это когда вместо

як();цуп();цоп();


Делается метод

ЯкЦупЦоп();


А як, цуп, цоп обьявляются небезопасными и делаются private. Эдакая забота о программерах (tm) от микрософт. Чтобы моск не перегревался.
Re[15]: минусы Ruby
От: Aquila http://www.wasm.ru
Дата: 20.07.06 18:18
Оценка: +4
Здравствуйте, VladD2, Вы писали:

VD>То есть халтуру в одной области оправдываем халтурой в другой? За тег <a> его автору морду мало набить. А уж называть метод генерирующих этот тег так же просто дибилизм. Что мешает назвать Метод как-то вроде MakeLinkReference? Ведь еще будет и MakeLinkTarget.


Лично я, если бы использовал библиотеку, генерящую HTML, ожидал бы, что методы, генерящие тэги будут совпадать с ними по имени, ибо это разумно. Если вместо того, чтобы логичным образом писать html.a(...), или html.strong(...), или html.img и получать предсказуемые результы, нужно лезть в хэлп и выяснять, что для генерации ссылки нужно писать Html.MakeLinkReference, Html.MakeThisBold и Html.InsertImageIntoIt соответственно, то, на мой взгляд, имеет смысл поискать более вменяемые альтернативы.
Re[4]: минусы Ruby
От: WolfHound  
Дата: 27.07.06 18:07
Оценка: :))) :)
Здравствуйте, eao197, Вы писали:

E>Вот еще один интересный сайт: Ohloh

Название сайта весьма символично...
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[10]: минусы Ruby
От: Трурль  
Дата: 02.08.06 07:53
Оценка: +1 :)))
Здравствуйте, mogadanez, Вы писали:

M>а почему тогда в том же немерле def означает define?

M>почему сократили? почему не полностью define? ведь если я первый раз вижу код на немерле и не писал на языках где есть def, я могу и с default перепутать, или с defolt

А уж догадаться что { означает begin на трезвую голову просто невозможно.
Re[5]: минусы Ruby
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 07.11.07 09:38
Оценка: -3 :)
Здравствуйте, Ligen, Вы писали:

L>ах да, конечно, тру пацаны называют функции исключительно в таком ключе:

L>
FindLFNorSFN_U
L>mkstemp
L>shmdt


L>я выбрал их совершенно cлучайно.

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

1 — х.з. Второе и третье очевидно mk — сокращение от make. shmdt — вероятно сокращения от "shared memory". 2 из 3-х — имхо хороший результат, учитывая то, что я ни С-программер, не низкоуровневый UNIX программер.
Ну, и, man никто не отменял
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[3]: минусы Ruby
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 01.06.06 04:43
Оценка: 6 (3)
Здравствуйте, VladD2, Вы писали:

VD>А что понятно? Мужик в общем-то прав по всем пунктам. Как раз твоя позиция выглядит более предвзятой.


Про те два пункта, где он был прав я и сказал в своем резюме. Пункт 4-й (про Ruby Way) -- это полный маразм. Поддержка XML-я непосредственно в язык -- это из той же оперы.

VD>На счет того, что я ругаю Руби — это не правда. Я ругаю необоснованную его рекламу.


О как! Т.е. отсутствие громких флеймов под заголовками "Ruby рулит" и "Ruby -- профанация не пройдет" -- это и есть необоснованная реклама. Особенно, если сравнивать с другими .NET-языками.

VD>А основными недостатками языка являются тормоза,


Ruby предназначен для быстрой разработки, а не для быстрого исполнения. Сама его природа (открытые типы, например) определяет, что он не сможет в принципе достигать скорости C++. А раз так, зачем корячиться.

К тому же здесь уже несколько раз приводились примеры, которые показывали, что в реальных задачах издержки Ruby составляют доли процентов от издержек остальных компонентов (ссылки сейчас искать некогда, но в Философии была тема про скорость импорта в БД данных из гигабайтных логов программой, написанной на F#; в Средствах разработки dmz сравнивал скорость парсинга логов на Python и Perl, туда же было добавлено сравнение с Ruby; в исходниках лежит мой проект svn-dumper-loader -- там svn dump на 160Mb репозитории работает минуту, а затем две минуты dump-файл архивируется bzip2, при таких показателях сам Ruby скрипт просто летает).

VD>отсуствие полноценной IDE (комплит, рефакториг, ...),


Да есть IDE для Ruby, как open-source (FreeRDE, Mongrel, RDT), так и коммерческие (Komodo).
Более того, Rubyist-ов совсем это не парит. Большинство используют VIM, emacs и TextMate (под MacOS), не испытывая при этом никаких сожалений.

VD>отсутствие статической типизации,


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

VD>черезмерная экономия на длинне идентификаторов в стандартной библиотеке,


Вот уж не замечал. Вот список методов, начинающихся на букву A из Core Library:
a (CGI::HtmlExtension)
abbrev (Abbrev)
abbrev (Array)
abort (Kernel)
abort (Process)
abort_on_exception (Thread)
abort_on_exception (Thread)
abort_on_exception= (Thread)
abort_on_exception= (Thread)
abs (Float)
abs (Complex)
abs (Fixnum)
abs (Numeric)
abs (Bignum)
abs2 (Complex)
absolute? (Pathname)
acos (Math)
acos (Math)
acos! (Math)
acosh (Math)
acosh (Math)
acosh! (Math)
add (ThreadGroup)
add (Set)
add (Benchmark::Tms)
add (Logger)
add! (Benchmark::Tms)
add? (Set)
add_builtin_type (YAML)
add_domain_type (YAML)
add_finalizer (ObjectSpace)
add_observer (Observable)
add_private_type (YAML)
add_ruby_type (YAML)
adler (Zlib::ZStream)
adler32 (Zlib)
ajd (Date)
ajd_to_amjd (Date)
ajd_to_jd (Date)
alias_method (Module)
alive? (Thread)
all? (Enumerable)
all_symbols (Symbol)
all_waits (ThreadsWait)
all_waits (ThreadsWait)
allocate (Class)
amjd (Date)
amjd_to_ajd (Date)
ancestors (Module)
angle (Numeric)
angle (Complex)
any? (Enumerable)
append_features (Module)
arg (Complex)
arg (Numeric)
args (NoMethodError)
arity (Method)
arity (UnboundMethod)
arity (Proc)
asctime (Time)
asin (Math)
asin (Math)
asin! (Math)
asinh (Math)
asinh (Math)
asinh! (Math)
assoc (Array)
at (Array)
at (Time)
at_exit (Kernel)
atan (Math)
atan (Math)
atan! (Math)
atan2 (Math)
atan2 (Math)
atan2! (Math)
atanh (Math)
atanh (Math)
atanh! (Math)
atime (File::Stat)
atime (Pathname)
atime (File)
atime (File)
attr (Module)
attr_accessor (Module)
attr_reader (Module)
attr_writer (Module)
autoload (Kernel)
autoload (Module)
autoload? (Module)
autoload? (Kernel)
avail_in (Zlib::ZStream)
avail_out (Zlib::ZStream)
avail_out= (Zlib::ZStream)

А вот фрагмент списка имен классов из Core Library:
Abbrev
ArgumentError
Array
Base64
Benchmark
Benchmark::Tms
Bignum
Binding
CGI
CGI::Cookie
CGI::HtmlExtension
CGI::QueryExtension
CGI::Session
CGI::Session::FileStore
CGI::Session::MemoryStore
Class
Comparable
Complex
ConditionVariable
Continuation
Data
Date
DateTime
Dir
EOFError
Enumerable
Errno
Exception
FalseClass
File
File::Constants
File::Stat
FileTest
FileUtils


Какие из них ты считаешь черезмерно сокращенными?

Ну и не нужно забывать, что в мире динамических языков процветают принципы code less и don't repeat yourself. Поэтому идентификаторы to_i, to_f, to_s, to_str, to_sym -- являются нормальными и удобными в использовании.

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


Это к пункту про статическую типизацию.

VD>текстуальность метарасширений.


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

VD>А сам язык как раз очень ничего.


Да уж... Язык-то как раз полезен теми вещами, которые ты только что здесь раскритиковал.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[12]: минусы Ruby
От: WolfHound  
Дата: 03.06.06 21:24
Оценка: 1 (1) +2
Здравствуйте, eao197, Вы писали:

E>Вот ты прикалываешься, а я перед использованием классов (в том числе и класса Data) читаю документацию по классу. При этом я узнаю не только про наличие метода ajd_to_jd, но и про его назначение и примеры использования. И таки да, смысл буквы "a" в ajd_to_jd сразу же сужается до Astronomical.

Когда я пишу на C# просто объявляю переменную нужного типа и смотрю на список методов который вываливает интелесенс. И так как разработчики библиотеки .НЕТ не страдали фигней с Huffman codes мне не нужны доки. Все понятно по именам методов. А если что-то непонятно то к каждому методу есть короткое описание и описание каждого из параметров. И только в самых маразматичных случаях приходится открывать MSDN.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[13]: минусы Ruby
От: Mamut Швеция http://dmitriid.com
Дата: 02.08.06 14:58
Оценка: 1 (1) +2
M>>Я не знал, и мне понятно не было — прочитал теперь понятно.
VK>Не могу себе этого представить. Ну что может быть в нем непонятного? Например здесь:
VK>
VK>beers(n : int) : string {
VK>  | 0 => "no more bottles of beer"
VK>  | 1 => "1 more bottle of beer"
VK>  | _ => $"$n bottles of beer"
VK>}
VK>


Для человека, незнакомого с pattern-matching'ом, здесь непонятно все
... << RSDN@Home 1.2.0 alpha rev. 655>> ... <<Banco De Gaia — Amber>> ...


dmitriid.comGitHubLinkedIn
Re[6]: минусы Ruby
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.06.06 16:00
Оценка: -1 :))
Здравствуйте, eao197, Вы писали:

E>Скорее наоборот -- люди пользуются Руби, им незачем кому-то что-то доказывать.


Ага. Оно и видно. Один пользуется, а рассуждений о Руби как будто на нем все пишут.

E>Ты хоть понял о чем сказал?

E>Попробуй внятно объяснить, в чем будет преимущество Nemerle или C# при решении задачи svn-dumper-loader-а
Автор: eao197
Дата: 29.05.06
.


Заметил, что к твоему сообщению ни одной оценки? Это потому что там огромное описание и написано на чем-то что далеко от народа.

Мне вот тоже влом тратить пол часа, чтобы прочесть все это ради спортивного интереса.

E>Я бы сказал, что это не ставит крест на целой группе языков.


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

E> Отнюдь. Скорее, это привлечет к ним внимание тех, кто не считает тебя пророком и всезнайкой. А уж самим языкам от твоего мнения о них ни тепло ни холодно.


А ты себя кем считашь рассказывая здесь в одиночестве сказки о Руби? Или мы только мою личность обсуждаем?

E>А разве тот же хэш мап не должен использоваться для запоминания ToString? А если ты знаешь, что метод преобразования в строку есть, то не все ли равно, называется ли он ToString или to_s?


Вопрос настолько неразумен, что я даже теряюсь. ToString полностью описывает смысл метода. А вот что значит to_s можно толко запомнить. Запомнить один to_s может и можно. Но таких вот сокращений в Руби пруд пруди.

В общем, я не понимаю о чем спор. Ты думшь я передумаю от того что ты скажешь "а мне нравится"? Нет. Я высказал свое мнение. Высказал его по твоей просьбе. Что ты еще хочешь?

VD>>Большей частью те что остались за кадром (видмо намеренно). Например, to_s. Но и из приведенных примеров перлов можно недергать не мало. Например, ajd_to_jd меня очень радует. Видимо метод преобразует Албанского Джона Дудаева в еще кого-то странного.


E>Тебе бы было понятнее, если бы он назывался ConvertAstronomicalJulianDayNumberToJulianDayNumber?


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

E> Тогда давай ты сразу, с ходу, без обращения к справочникам объяснишь, чем отличается Astronomical Juluan Day от Julian Day.


А зачем? Главное, что я понял, что деалает метод. А уж подробности исчисления дат меня не интересует. Мне достаточно того, что мне он на фиг не упал. А вот если бы он был мне нужен, то я знал бы эти подробности.

E>

E>А вообще спасибо за смешной ответ. Читать было весело.

Рад что тебе весело. Меня вообще радует когда я кого-то радую. Будь то попутчик в лифте или представитель одного из направлений нетрадиционного секса с компьютерами.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: минусы Ruby
От: Aquila http://www.wasm.ru
Дата: 20.07.06 17:36
Оценка: :)))
E>>Я бы сказал, что это не ставит крест на целой группе языков.
VD>Ну, можешь поглядеть каков интерес к вашим Руби и Питонам на этом сайте. Из с криптов массовое распространение получил ЯваСкрипт и тот потому что в броузеры вмонтирован и по факту является единственным средством их расширения.

Есть довольно известный скриптовый язык без статической типизации, получивший относительно широкое распространение. Называется PHP. Подробнее о нём можно прочитать здесь.
Re[22]: минусы Ruby
От: Cyberax Марс  
Дата: 02.08.06 12:52
Оценка: +2 -1
mogadanez wrote:
> C>Родная Mac OS X не ставится на обычные компьютеры. А в EULA у них
> C>прописано, кстати, что запрещено ставить Mac OS на компьютеры, не
> C>сертифицированные Apple'ом.
> да, но в статистику такие компы тоже должны попадать.
Их такой мизер, что они не будут видны под микроскопом.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[6]: минусы Ruby
От: VladD2 Российская Империя www.nemerle.org
Дата: 17.03.07 02:33
Оценка: +1 -1 :)
Здравствуйте, eao197, Вы писали:

E>Боюсь, что помочь не смогу, пользуюсь VIM-ом. Отладчик никогда не запускал, с отступами, переименованием и отладочными печатями так же проблем не было (но это, может быть, всего лишь следствие моего стиля работы).


Надо это куда-то записаать. А то жаль такую фразу "С закатом солнца в ручнуюю проблем не было (но это, может быть, всего лишь следствие моего стиля работы)".
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: минусы Ruby
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.06.06 14:21
Оценка: 21 (1) +1
Здравствуйте, eao197, Вы писали:

E>Здравствуйте, VladD2, Вы писали:


E>>>И я сильно сомневаюсь, что количество информационных ресурсов, на которых упоминается C# больше, чем тех, на которых упоминается C.


VD>>1. Количество упоминаний С посчитать практически невозможно, так как это просто буква алфавита. Даже C# тяжело, так как это в общем-то нота. Ява это еще по совместительству кофе, мотоциклы, остров и даже среда выполнения.


E>У них написано, что они делают поиск по

E>

E>+"<language> programming"


И хрен ли даст такой поиск? Название книг?

Вот на РСДН твой запрос дает для С — 2 вхождения, для С# — 1, для С++ — 21. Соотвествует это реальному раскладу сил?

Ладно, ты скажешь, что дело в том, что это русский сайт (хотя чем русские то плохи?).
Сделаем такой запрос:
site:rsdn.ru +"C++ программирование" — опа! одно вхождение!
теперь такой:
site:rsdn.ru +"C# программирование" — класс! На РАСДН вообще нет C#!
Нет так же и С, и Явы.

В общем, вычисление популярности языков по Гуглю — это как астралогический прогноз. Кто хочет тот такой прогноз и дает.

VD>>2. Измерять популярность языков можно только посчитав количество активно программирующих на них людей или количество развиваемых на них проектов.


E>С этим так же все кореллируется. На SourceForge самое большое количество проектов на Java, C++ и C (что-то порядка 16000 на каждого).


Ни хрина с этим не коррелирует. Смотри цыфры тщательнее. С там за последние 5 лет первым не был. Плюсь С записывают в доброю половину проектов просто потому, что есть один исходник на С. Как в прочем и разные Питоны. Ну, и главное, это забавный рейтинг популярности, так как он вообще не учитывает коммерческой разработки. Вон на нашем сайте сидят в основном люди из коммерции и рассклад здесь совсем иной. "С" нет и в помине. Аутсайдер в ОпенСорсе — C# борется с С++ за звание лидера. А наш сайт — это самый большой программистский портал рунета. Скажу больше. Вряд ли найдется сайт где даже форум по Яве был бы более активен. Можно конечно сказать, что это мол только рунет... Ну, ладно, зайдем на http://www.codeproject.com. Что мы читаем во первых строках этого ресурса?

Your place for 12,464 free C++, C# and .NET articles, code snippets, discussions, news and the best bunch of developers on the net.


О как?! Опять C++ и C#. Забавно, а ведь это явно не маленький международный портал. Идем на http://www.codeguru.com/
Опа! И тут в меню языки идут С++, C#, VB. Если зайти на IBM или про Явские сайты, то там будет засилие Явы.

Что же всех их объеденяет? Ах да, там нет С.

Ладно зайдем с другой стороны. Вот например, есть коммерческая контора ДжетБрэйнс. Делает средства рефакторинга и автоматизации для средств разработки. Чем же они занимаются? Опа, дотнет и Ява. Я понимаю почему не С++. Язык сложный. А почему не С? Ведь уж для него точно можно было бы рефакторинг залудить! Да на хрен он никому не упал. Старперы один фиг обойдутся грепами. Да и не много их. А современные программисты выбирают в основном из хтих трех языков — C++, C#, Java.

E>Может быть под Windows так и есть, но вот про Unix я бы не стал так говорить.


Мля. Еще однин миф. Ребатки. Линукс можно заметить невооруженным взглядом только в веб-решениях. Виндовс — это большая часть рынка. И именно потому большинство коммерческих контор работают на Виндовс. Другие ОС (т.е. не Виндовс и не Линукс) вообще видно только в микроскоп. Людям нужны стандарты и выбор ПО, а не трах с диковинными ОС. Так что если вы попали в пару процентов у которых заказчика кровь из носу нужны диковинные ОС или даже Линукс, то воспринимайте это адекватно, а не как будто Виндовс это одна из диковенных ОС.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: минусы Ruby
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 07.03.07 08:47
Оценка: 13 (2)
Здравствуйте, Курилка, Вы писали:

К>Собственно хотел предложить для прочтения (и обсуждения тоже) статью 5 things I hate about Ruby


В последнее время промелькнуло несколько ссылок, которые позволяют оценить ситуацию с такими недостатками Ruby, как скорость выполнения и отсутствие IDE:

Ruby Implementations Shootout: Ruby vs Yarv vs JRuby vs Gardens Point Ruby .NET vs Rubinius vs Cardinal
Behind The Scenes: JRuby 0.9.8 Released!

Ruby / Rails IDE Comparison : Idea, Netbeans, RadRails
Two Demos: JRuby on Rails and Advanced Ruby Editing in NetBeans!


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re: минусы Ruby
От: Зверёк Харьковский  
Дата: 28.05.06 20:29
Оценка: 1 (1) +1
Здравствуйте, Курилка, Вы писали:

К>Собственно хотел предложить для прочтения (и обсуждения тоже) статью 5 things I hate about Ruby

К>Особенно не положительным 4-й пункт кажется: навязываемый "Ruby Way", который ещё и не имеет однозначной трактовки.
К>З.Ы. Как-то не нашёл куда логичнее будет это написать: руби почти насквозь императивный, поэтому в декларативные не лезет, а среди языков его нет...

ОбвинениеМое мнениеНадежды на лучшее
1.Ruby is slowДа, действительноRuby 1.9 несколько быстрее. YARV (Ruby VM beta, будет использован в Ruby 2.0) быстрее на порядки, но пока глючит
2. Ruby's development process is slow.Нет. В 1.9 (experimental branch) новые фичи возникают достаточно часто
3. Ruby's "official" documentation is sparse and, in some cases, nonexistent.Это полуправда. Действительно, в документации описаны подробно не все стандартные библиотеки, но по всем сгенерирована автоматическая документация — по крайней мере, список основных классов/методов/параметров можно узнать быстро.Постепенно исправляется энтузиастами. Текущее покрытие подробной документацией ~70% стандартной библиотеки
4. Screw the Ruby WayБред.
5. Ruby has shitty XML supporНе понимаю этого обвинения
FAQ — це мiй ай-кью!
Re[18]: минусы Ruby
От: CrazyPit  
Дата: 06.06.06 11:45
Оценка: 1 (1) +1
Здравствуйте, eao197, Вы писали:

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


Название tr внятное для Unix-оидов (консольная команда совершающая соотвестующее преобразование), а среди разработчиков руби много юниксоидов — отсюда название. А вообще по теме сокрщений у меня такое мнение. Сокращения хороши, но приемлемы только в хакерском коде, т.к. в производственной разработке нужнен меньший порог вохождения и большая строгость. Но сами по себе сокращения явление нормально и постоянно применяемое в жизни, вспомните сколько из тех слов коорые вы используете в самом деле сокращения. Но сокращения должны быть тоже внятыми и стандартными. Например str вместо string или IO вместо InputOutput. Ещё есть такое мнение что чем меньше код, тем кажеться что он совершает меньше действий... Об этом Пол Грэм хорошо написал, и вообще он много чего написал о сокращения и их пользе. Также можно вспомнить математику, которая без сокращений была бы раз этак в 10 больше по объёму и более запутанной. Но сам я например очень редко даю названия в виде сокращений, память плохая, но чужие сокращения использую с удовольствием.
Re[5]: минусы Ruby
От: IT Россия linq2db.com
Дата: 28.05.06 19:09
Оценка: :))
Здравствуйте, VladD2, Вы писали:

VD>ОК, раз тут неумеющих думать на шаг вперед большинство, то разжую смысл свои слов так чтобы дошло до последнего американца.


Я всё равно ничего не понял
Тупею на чужбине
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[9]: минусы Ruby
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 02.06.06 09:52
Оценка: +2
Здравствуйте, Left2, Вы писали:

VD>>>Из с криптов массовое распространение получил ЯваСкрипт и тот потому что в броузеры вмонтирован и по факту является единственным средством их расширения.


E>>Да уж, это вообще но комментс.

E>>Хотя, все же спрошу: JavaScript где-нибудь как самостоятельный язык программирования используется (без браузера и не как встроенный язык)?

L>Да — в Windows. .js файлы испольняются на ура, так же как и VBS. Очень удобная альтернатива bat-файлам


Чтож, век живи -- век учись. Буду знать.
Но тогда нужно перефразировать Влада, чтобы быть точным: "Из скриптов массовое распространение под Windows получил ЯваСкрипт...".


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[9]: минусы Ruby
От: Kluev  
Дата: 02.06.06 10:26
Оценка: +2
Здравствуйте, Left2, Вы писали:

VD>>>Из с криптов массовое распространение получил ЯваСкрипт и тот потому что в броузеры вмонтирован и по факту является единственным средством их расширения.


E>>Да уж, это вообще но комментс.

E>>Хотя, все же спрошу: JavaScript где-нибудь как самостоятельный язык программирования используется (без браузера и не как встроенный язык)?

L>Да — в Windows. .js файлы испольняются на ура, так же как и VBS. Очень удобная альтернатива bat-файлам


И чего же удобного? все сделано через ж-пу. Чтобы банальные вещи в файловой системе сделать надо FileSystemObject создавать.

вот bash это действительно удобная альтерантива бат-файлам.
для примера
mkdir -p dir/{foo,bar,dummy}

Производит:
dir
dir/foo
dir/bar
dir/dummy
Re[13]: минусы Ruby
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.06.06 22:39
Оценка: +2
Здравствуйте, WolfHound, Вы писали:

WH>Когда я пишу на C# просто объявляю переменную нужного типа и смотрю на список методов который вываливает интелесенс. И так как разработчики библиотеки .НЕТ не страдали фигней с Huffman codes мне не нужны доки. Все понятно по именам методов. А если что-то непонятно то к каждому методу есть короткое описание и описание каждого из параметров. И только в самых маразматичных случаях приходится открывать MSDN.


Кстати, поймал себя на мысли, что чаще открываю Рефлектор, чем МСДН.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Очередной сеанс языкометрии :)
От: Андрей Хропов Россия  
Дата: 03.06.06 23:37
Оценка: +2
Здравствуйте, VladD2, Вы писали:

VD>2. Измерять популярность языков можно только посчитав количество активно программирующих на них людей или количество развиваемых на них проектов.

Вот я сделал такую попытку, посмотрев на количество результатов выводимых по проектам в которых используется тот или иной язык на sourceforge.net.
Вот что получилось (список не полный, смотрел то что мне интересно):

C — 16664
C# — 3984
C++ — 18125
COBOL — 9
Common Lisp/
Emacs Lisp/
Lisp/
Scheme — 40+34+328+210=512
D — 35
Forth — 61
Fortran — 194
Haskell — 55
Java — 19321
JavaScript — 3656
MATLAB/
Simulink — 78+5=83
Oberon — 5
Objective C — 850
OCaml — 85
Nemerle — нету такого (0)
Perl — 6352
PHP — 13917
Prolog — 116
Python — 5212
Ruby — 560
Smalltalk — 64
Tcl — 912
Visual Basic — 2242
VB.NET — 583

Конечно, это сравнение не может претендовать на абсолютную объективность (только open source, многие проекты на D,Python,Ruby лежат на родных сайтах и т.п. ),
но тем не менее интересно. Кстати, положение самых популярных языков приблизительно похоже на рейтинг TCPI.

VD>3. С уже лет 10 как явно проигрывает по популярности С++. Это как минимум. И если кто-то говорит обратно, то его остальные выводы вызвают огромные сомнения.

Проигрывает-то он проигрывает. Но проектов живых полно еще. Все-таки самый портабельный язык.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[15]: минусы Ruby
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 04.06.06 17:56
Оценка: +2
Здравствуйте, VladD2, Вы писали:

VD>А я и задумался и не раз. Еще даже до того как узнал твое личное мнение по этому вопросу. Прочел ни одну статью по этому поводу. Потому и уверен в данной оценке.


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

E>>Например, в CGI::Extension есть метод a(). И он является генератором HTML тега <a>.


VD>То есть халтуру в одной области оправдываем халтурой в другой?


Если чесно, мне по барабану, является ли <a> в HTML халтурой или нет. Но, когда мне приходится генерировать HTML из программы, мне удобно пользоваться в программе такими же понятиями, как и в HTML. Это можно назвать приближением к предметной области.

E>> Вызывает ли его использование в контексте генерации HTML-страницы проблемы с его использованием?


VD>100% — ДА. И если ты заучил эту шифровку — это ничего не значит для окружающих.


Окружающих Ruby программистов или просто окружающих? Если просто окружающих, то они идут лесом.

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


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

E>>Да уж. Если переписать как ToArray, ToHash, ToInt, ToIO информативности сразу же добавиться. Просто на порядок.


VD>Я о ToIO или to_io. Написание тут значения не имеет. Само название бессмысленно.


Название имеет смысл для Ruby программистов, т.к. IO -- это один из базовых классов в Ruby для организации ввода вывода. Поэтому to_io (или ToIO) означает, что объект может сконвертироваться в реализацию класса IO. В C++ это было бы аналогом возвращения объекта std::iostream.

E>>>>to_proc -> Proc


VD>>>Преобразовать в процессор? Однако Руби силен!


E>>Дурку выключи.


VD>Дурку? Я залез в Лингво... Единственный перевод — процессор. proc. еще переводится как:

VD>Какой из переводов предпочесть? Протокол? Процедура? Процесс?

В документацию по Ruby библиотеки нежно было залезть. Proc -- это название класса, который используется для работы с блоками кода. Соответственно, to_proc возвращает блок кода, каким-то образом связанный с объектом. Мы же здесь о Ruby все-таки разговариваем, следовательно нужно как-то ориентироваться в понятиях языка и его библиотеки.

VD>Так что это ты выключи дурку и ответь наконец на поставленный мной вопрос. Что дает использование невнятных сокращений?


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

VD>>>Ну, и ответь на вопрос. Что сэкономили авторы на этих сокращениях?


VD>И что тут предпочтительного? Вот тот же код причем на статически типизированном языке:

VD>
VD>def HexStringToIntString(hex) { int.Parse(hex, NumberStyles.HexNumber).ToString() }

VD>foreach (line in File.ReadAllLines(path))
VD>  PutString(regexp match (line)
VD>  { | @"^(?<prefix>.+)""router::trx\.(?<hexStr>[^""]+)""(<sufix>.+)$"
VD>        => prefix + HexStrToIntStr(hexStr) + sufix
VD>    | _ => line
VD>  });
VD>

VD>И это еще бещ учета того, что ToString можно вывзать неявно.

Имхо, этот код менее понятен, чем мой. Так же он требует от читателя знания того, что указанный в регулярном выражении в угловых скобках идентификатор преобразуется в переменную. Если же использовать неявные фокусы Ruby, то можно еще интереснее:
while gets
    if ~ /^(.+)"sms_router::rosbank\.([^"]+)"(.+)$/
        puts "#{$1}#{$2.to_i(16)}#{$3}"
    else
        puts $_
    end
end



VD>Подытожим. Правильно ли я понял, что засилие бессмысленных одно-двух-буквенных идентификаторов вызвано стремлением впихунть в одну строку как можно больше фунций? То есть является следствием (или причиной) неумелой декомпозиции кода?


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

VD>Или все же есть более весомая причина?


Думаю, это тебе нужно у Matz спрашивать. Я всего лишь использую уже существующие имена и проблем у меня это не вызывает.

VD>Ладно, по to_i еще можно догадаться, что делает фукнция. Да и запомнить это не очень сложно. Но как догадаться что такое tr, tr_s, sub, rjust, ljust, chomp... ?


А ты придумай для tr и tr_s внятные имена
sub, rjust, ljust -- понятны без проблем.
chomp -- хрен знает откуда такое имя, может быть автор хорошо знал английский. Но remove_trailing_separators вместо chomp, имхо, это так же не есть хорошо.

VD>Это оно экономится нафигачиванием в одну строку тонны малопонятных конструкций что ли? Сори, я или идиот, или не могу понять, чем:

VD>
VD>m[1] + m[2].to_i(16).to_s + m[3]
VD>

VD>лучше чем:
VD>
VD>$"$prefix $(hexStr.ToInt(16)) sufix"
VD>

VD>или чем
VD>
VD>prefix + HexStrToIntStr(hexStr) + sufix
VD>


По моему, они эквивалентны. Только в случае с HexStrToIntStr тебе пришлось делать функцию, которая выполняет то же самое, что и комбинация to_i(16).to_s. При том, что название HexStrToIntStr имеет такую же смысловую нагрузку, что и to_i(16).to_s.

VD>По всей видимости наше понятие о прекрасном сильно разнится.


Это уж точно. Например, как мне помнится, абстрактная живопись тебе не нравится.

VD>Но вкусы это одно. А вот понятность это другое. Мне пришлось пролезь по Интернету чтобы понять, что делает to_i(16), а вот понять, что делает HexStrToIntStr() или ParseHexStr() ни для кого не составит труда. Не согласен?


Нет, не согласен. Ruby программист не будет лазить по интернету, чтобы понять, что такое to_i(16). Так же как и дотнетчик не будет искасть в MSDN описание int.Parse(hex, NumberStyles.HexNumber).

E>> Нужно требовать, чтобы имена (не только в публичных интерфесах) были не противоречивыми и понятными, самодокументирующими по возможности.


VD>Сам себе противоречишь. to_a, а темболее tr не являются ни не противоречивыми и ни понятными, ни самодокументирующими. То что ты их заучил ничего ровным счетом не значит. Я их учить не хочу.


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

VD>Ну, а то что коротких имен можно в строку больше запихать,


Об этом, насколько я помню, не было и речи. Цель не в том, чтобы в одной строке было больше идентификаторов. А в том, чтобы было меньше строк. А в строке -- меньше идентификаторов. А идентификаторы короче, при сохранении той же читабельности. Короче принцип code less в чистом виде.

VD>Но добиваться краткости путем потери информации — это все равно что не мыться чтобы сэкономить время.


Видишь ли, код Хаффмана ценен тем, что он не теряет информации. Совсем. Он только позволяет записать ее компактнее.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re: минусы Ruby
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 27.07.06 14:54
Оценка: :))
Здравствуйте, Курилка

Вот веселый и хороший разбор ситуации вокруг Ruby вообще и RubyOnRails в частности

Who are those who are benefiting from Ruby on Rails? Answer: O'Reilly Publishing, the authors Bruce Tate and Dave Thomas and a handful of consultants.



SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[9]: минусы Ruby
От: mogadanez Чехия  
Дата: 01.08.06 15:58
Оценка: -2
VD>Так вот я понял бы, что значит str, но я так же понимаю почему это плохо. Люди стремятся к единообразию и если допустить str в публичном интерфейсе, то завтра появится def для обозначения defaulte, а после завтра появится ajd_to_jd... и пошло, поехало. В итоге вместо кода получается шифровка. Добавляем к ней случайные опечатки в именах переменных (мы и это считаем мелочами) и вот уже на горизонте мы видим результат который без пол литра не понять.

а почему тогда в том же немерле def означает define?
почему сократили? почему не полностью define? ведь если я первый раз вижу код на немерле и не писал на языках где есть def, я могу и с default перепутать, или с defolt

такая же фигня с параметром "_" — человек первый раз видящий его хрен догадается что он значит.
Re[20]: минусы Ruby
От: Cyberax Марс  
Дата: 02.08.06 11:30
Оценка: +2
mogadanez wrote:
> M> На специально заточенные под МакОсь компы. Причем настолько
> специально, что Эпплу под давлением общественности пришлось выпускать
> патч, позволяющий ставить и Винду на те же компы.
> Ты отстал от жизни. или просто заблуждаешься, ставиться легко на простой
> комп на котором всю жизнь в WinXP работали.
Вранье. Есть взломанная версия Mac OS X, в которой убрана
проверка оборудования.

Родная Mac OS X не ставится на обычные компьютеры. А в EULA у них
прописано, кстати, что запрещено ставить Mac OS на компьютеры, не
сертифицированные Apple'ом.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[10]: минусы Ruby
От: Vermicious Knid  
Дата: 02.08.06 13:00
Оценка: +2
Здравствуйте, mogadanez, Вы писали:

M>а почему тогда в том же немерле def означает define?

def это все таки не название(идентификатор), а ключевое слово и встречается в коде оно намного чаще чем некое гипотетическое название метода.

M>почему сократили? почему не полностью define?

Потому, что ключевые слова для деклараций переменных/постоянных значений в большинстве языков с необязательной декларацией типов принято делать короткими. Например в C# 3.0 и JavaScript это ключевое слово var, в SML — val, в Scala — var и def.

M>ведь если я первый раз вижу код на немерле и не писал на языках где есть def, я могу и с default перепутать, или с defolt

Я тебе не верю. Надо обладать невероятной степенью тупизны, чтобы не понять с первого взгляда что означает def в коде на Nemerle.

M>такая же фигня с параметром "_" — человек первый раз видящий его хрен догадается что он значит.

Тоже не верю. "_" выглядит очень интуитивно понятно, особенно в match выражениях. Кроме того "_" это очень распространенная идиома. Я например имел о ней представление задолго до знакомства с Nemerle, из Пролога, SML, Haskell. В Nemerle правда "_" еще используется для конструирования лямбда-выражений с безымянными аргументами, но даже в этом случае я был знаком с чем-то приблизительно похожим, а именно с boost::lambda.
Re[5]: минусы Ruby
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 07.03.07 17:41
Оценка: +1 :)
Здравствуйте, Lloyd, Вы писали:

П>>>PS Хотя питон мне все равно пока нравится больше


E>>Может быть вот это
Автор: Евгений Охотников
Дата: 03.03.07
склонит чашу весов в сторону Ruby?

E>>)

L>Оглавление?


А то!
Те, кто не может ждать три месяца до публикации в online могут поискать RSDN Mag в продаже. Ну или вспомнить, что у меня в профайле мыло указано


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[9]: минусы Ruby
От: Зверёк Харьковский  
Дата: 01.06.06 15:31
Оценка: 20 (1)
Здравствуйте, Mamut, Вы писали:

ЗХ>>Тогда подпишись на ruby-talk


M>Это где?


Сайт ruby-lang.org; ссылка на главной странице озаглавленная Mailing List, приводит сюдой:
http://www.ruby-lang.org/en/20020104.html
Можно читать через почту, или через comp.lang.ruby
FAQ — це мiй ай-кью!
Re[4]: минусы Ruby
От: Cyberax Марс  
Дата: 28.05.06 16:43
Оценка: 14 (1)
eao197 wrote:
> C>Рекомендую добавить в mxx_ru кэш зависимостей include'ов — на ноутах с
> C>медленным винтом значительно помогает.
> Да, это в планах. Как и еще целая куча фич
Могу еще фичу придумать — конвертер из .jam-файлов в Mxx_ru

Берете мой http://elewise.com/pubrepos/BuildPort/trunk/ и пишите
правила, которые будут выводить список целей в виде файлов проекта для
Mxx_ru (вместо стандартных правил, запускающих компиляцию).

Как показал беглый осмотр — файлы проектов самого Boost'а должны без
особых проблем конвертироваться.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[8]: минусы Ruby
От: Left2 Украина  
Дата: 02.06.06 09:32
Оценка: 14 (1)
VD>>Из с криптов массовое распространение получил ЯваСкрипт и тот потому что в броузеры вмонтирован и по факту является единственным средством их расширения.

E>Да уж, это вообще но комментс.

E>Хотя, все же спрошу: JavaScript где-нибудь как самостоятельный язык программирования используется (без браузера и не как встроенный язык)?

Да — в Windows. .js файлы испольняются на ура, так же как и VBS. Очень удобная альтернатива bat-файлам
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[19]: минусы Ruby
От: raskin Россия  
Дата: 05.06.06 07:15
Оценка: 14 (1)
Mamut wrote:
> Потому что она означает *tr*anslate. А вот что обозначает tr в Руби — ??

Это старая традиция из shell, на самом деле.. Эта команда появилась в
UNIX до написания первого POSIX (замечу, что тогда с completion было
туго), да так осталасть по традиции. Люди, которые захотят её
использовать в Рубине, скорее всего, пользовались ею и раньше. И,
кстати, заголовок man tr: tr — translate or delete characters .
Насколько здесь хорошо translate — другой вопрос.
Posted via RSDN NNTP Server 2.1 beta
Re[7]: минусы Ruby
От: Зверёк Харьковский  
Дата: 01.06.06 13:43
Оценка: 10 (1)
Здравствуйте, Mamut, Вы писали:

E>>Кстати, для RubyOnRails на основе Eclipse делают IDE: RadRails


M>Пользуюсь, не нравится Хотя под винду лучше и нет (сейчас качаю триал Комодо, посмотрю, что там).


А ты таки стал писать на Ruby? Тогда подпишись на ruby-talk
Там иногда проскакивают вот такие штуки:

http://www.sapphiresteel.com/About-Ruby-In-Steel

Steel is a free Ruby language add-in for Microsoft’s Visual Studio 2005. It provides an editing environment for Ruby programs complete with syntax colouring and the ability to run console applications with one keystroke. Over the coming months we shall be adding more features to the Steel IDE to provide an easy, accessible Ruby coding environment for VS2005 users.


Дисклямер: сам не пробовал, бо мой Celeron900 VS2005 не потянет.
FAQ — це мiй ай-кью!
Re[3]: минусы Ruby
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 27.07.06 18:03
Оценка: 9 (1)
Здравствуйте, Mamut, Вы писали:

M>Замечу, что речь идет не о Руби вообще, а о Rails в частности. Кстати, в Ruby Community периодически всплывает мысль — а как бы Rails не стал убийцей Руби в том смысле, что как бы Руби не стало "просто я зыком, на котором написан Rails".


Это вряд ли. Я же выбрал Ruby совсем для других целей и еще до того, как о Rails заговорили

M>Готов ли Rails к Enterprise? Скорее всего, нет. Именно и-за прооблем, описанных в посте — хранимые процедуры, скорость, проблема грамотной конфигурации веб-сервера (см. Time For A Grown-Up Server: Rails, Mongrel, Apache, Capistrano and You). Хотя, с другой стороны, несколько серьезных проектов используют Rails(особенно стоит выделить A List apart, BaseCamp, eins.de (об их мучениях — здесь)). Но это — другая история, для форума Веб программирование.


Вот еще один интересный сайт: Ohloh -- каталог OpenSource проектов с их некоторыми метриками и позволяющий сравнивать между собой разные проекты: http://www.ohloh.net/compare/detail?projects=scons+apache_ant


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[3]: минусы Ruby
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 07.03.07 17:35
Оценка: 4 (1)
Здравствуйте, Пацак, Вы писали:

П>PS Хотя питон мне все равно пока нравится больше


Может быть вот это
Автор: Евгений Охотников
Дата: 03.03.07
склонит чашу весов в сторону Ruby?


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[16]: минусы Ruby
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.06.06 20:50
Оценка: 3 (1)
Здравствуйте, FR, Вы писали:

FR>В этом вопросе я скорее ближе к твоей позиции чем к позиции eao197, но его код (не смотря на птичий для меня синтаксис руби) понятнее чем твой.


Хм,
prefix + HexStrToIntStr(hexStr) + sufix

мене понятен чем
m[1] + m[2].to_i(16).to_s + m[3]


Во истину о вкусах не спорят.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[19]: минусы Ruby
От: VladD2 Российская Империя www.nemerle.org
Дата: 05.06.06 15:14
Оценка: 3 (1)
Здравствуйте, Kluev, Вы писали:

K>Причем тут вкусы? to_i(16).to_s — понятно любому сишнику без кометариев. Хинт atoi и itoa. Только вместо a — s, и первые части (a)toi и (i)toa поскипаны т.к. это не функции, а методы обьектов. Вообщем to_i и to_s — это clear as mud. А вот что такое HexStrToIntStr — от этого действительно можно впасть в ступор. Типично микросовтовский подход, не хватает только добавить булевый параметр, если true то Hex->Int, если false то Int->Hex.


Финиш... сполз под стол... жувот болит от смеха. Если это не намеренная клаунада, то разговор нужно закрывать, так как играть в дурдом это уже перебор.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: минусы Ruby
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 09.03.07 10:37
Оценка: 2 (1)
Здравствуйте, Anton Batenev, Вы писали:

AB>По этому, если кто подскажет IDE с нормальным отладчиком, комплитом и средствами рефакторинга (бесплатную естественно) буду премного благодарен, т.к. сейчас трачу огромное количество времени на банальные вещи типа переименовывания, расставления отступов и разбора отладочной информации, которую приходится выводить на экран.


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

Может быть NetBeans (здесь показано и реформатирование кода) или Ruby-In-Steel (feature-list).


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[16]: минусы Ruby
От: Курилка Россия http://kirya.narod.ru/
Дата: 05.06.06 08:36
Оценка: 1 (1)
Здравствуйте, eao197, Вы писали:

E>chomp -- хрен знает откуда такое имя, может быть автор хорошо знал английский. Но remove_trailing_separators вместо chomp, имхо, это так же не есть хорошо.


Вообще по ходу это дело они стырили из перла (руби же как человеческая замена перла иногда позиционируется), а в перле может оно тоже с какого-нибудь баша и иже с ним пришло.
Re[21]: минусы Ruby
От: raskin Россия  
Дата: 05.06.06 15:31
Оценка: 1 (1)
VladD2 wrote:
> Здравствуйте, raskin, Вы писали:
>
> R>Это старая традиция из shell, на самом деле.. Эта команда появилась в
> R>UNIX до написания первого POSIX (замечу, что тогда с completion было
> R>туго), да так осталасть по традиции. Люди, которые захотят её
> R>использовать в Рубине, скорее всего, пользовались ею и раньше. И,

> Здорово. А как быть людям не использовавшим ее до этого (а похоже таких

> большинство на этом сайте)?
Судя по тому, что тут были неверные трактовки её документации — она им
низачем не упадёт. Это скорее для локальных UNIX-административных дел
было введено, а тот, кто этим станет заниматься всё равно *список*
POSIX-утилит мог бы и прочитать. Да, этого большинство здесь делать не
будут. Да, это им и не надо. Но так везде. Рубин же позиционируется как
гуманный PERL, который расширенный shell.
disclaimer. ruby не использую; часто пишу на shell; и это мне нравится.
Даный спор мне напомнил график трудоёмкости решения задачи от объёма на
разных языках/при разных подходах. На них всегда честно рисуют — сложная
система с большим числом связей реализуется на мощных языках с
использованием качественных, объёмных, проработанных технологий;
простые/разбитые на простые и слабо связанные — на чём-то скриптовом,
тоже качественном, но в другом направлении.
Posted via RSDN NNTP Server 2.1 beta
Re[17]: минусы Ruby
От: mogadanez Чехия  
Дата: 02.08.06 11:30
Оценка: 1 (1)
VD>Я правильно понимаю, что Руби-программисты это отдельная каста? Мне не нравятся касты. Особенно если для вхождения в оную нужно забить голову заучиванием невнятных идетификаторов.
....
VD>А чтобы знать что означает что нужно в голове создать хэш-табчичку и запоминать i -> integer, s-> string, tr -> ???... Сори у меня уже хэш испортился.
...
VD>Вот iostream, хотя лучше io_stream или IO.Stream, ну, да не важно, так вот iostream смысл имеет, а to_io — это снова в хэш-табличку.
...
VD>Ясно. Снова в хэш-табличку...
...
VD>Многие внятные, а остальные многие... правильно в хэш-табличку.

Влад, ты знаешь сказку про мапперов и пакеров? хеш-табличка — это типичный пакер.




VD>Я правильно понимаю, что Руби-программисты это отдельная каста? Мне не нравятся касты. Особенно если для вхождения в оную нужно забить голову заучиванием невнятных идетификаторов.

1. Ты не любишь касты или касты в которые не входишь?

Увы, мэйнстрим-языки типа Java, C++, C# и VB – не те инструменты, которые необходимы для победы в этой нелегкой борьбе. C++, при всей его гибкости, все же недостаточно гибок, и скорость разработки на нем очень низка. К тому же этот язык не прощает ошибок и требует огромных усилий при тестировании. Остальные упомянутые языки, хотя и являются замечательными и простыми в использовании языками программирования, именно этими качествами и плохи в данной ситуации, так как не предоставляют мощных языковых средств, позволяющих радикально упростить решение сложных задач, но в то же время легки для освоения и способствуют снижению порога вхождения в профессию.

(с) Вводная статья по языку Nemerle


Йо... оказывается Nemerle тоже призван повысить порог вхождения? тоже каста?
или просто ты ниже порога вхождения в Руби и тебя это задевает?

2.

....забить голову заучиванием невнятных идетификаторов.

это опять про пакеров.



VD>Ничего страшного. Я это переживу. Сделать это нужно ровно однажды. Зато потом мне не прийдется распозновать в твоих кракозябрах что собственно происходит. Я просто прочту имя функции, пойму что она делает и пойму суть выражения. Смотреть ее мне не прийдется. Это, кстати, на любом языке решение верное.

...
VD>Правда? А я провел двадцать минут в интернете чтобы понять что же делает to_i(16). Да и не просто из алгоритма вычленить суть. Все же английский понятнее. Не находишь?

я не знаю Руби( 2 -3 скрипта на нем не в счет ), и не лазал в интернет за описанием, и пишу я в основном на C#( 70% ) и JS (30%), но глядя на to_i(16) я вполне догадываюсь что она делает. Причем небыло даже тени сомнения или нескольких вариантов. Потому что у меня в голове построена карта. Нанеся на карту несколько точек, можно достроить ее в местах где ты небыл, и даже если это достроение не совпадет с реальностью, когда ты придешь на место, надо будет всего лишь немного подправить карту.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Re[4]: минусы Ruby
От: VladD2 Российская Империя www.nemerle.org
Дата: 28.05.06 18:20
Оценка: :)
Здравствуйте, Андрей Хропов, Вы писали:

АХ>Здравствуйте, VladD2, Вы писали:


VD>>Прочтя этот ответ я понял, осознал главную причину по которой нельзя использовать Руби в серьезных проектах. "это же OpenSource со всеми вытекающими" А вытекающие кривизна.

АХ>Я думаю "За и против OpenSource" — это отдельная СВ. Давай здесь только про Руби.

АХ>P.S. Nemerle — это тоже Open source .


Я иногда балдею с узости взглядов царящих на РСДН. Я уже давно замечаю, что если после шутски не вставить слово "лопата", то никто не засмеется. И давно замечаю, что нужно разжевывать и в рот закладывать.

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

Отмазки eao197, а по другому это назвать тяжело, буквально напичканы указанием на то, что Руби ОпенСорс и мол все беды от этого. Так вот если, что-то дерьмовое, то она и в фарике дерьмовое и не фига пинять на обстоятельства. А то как в "Необыкновеннм чуде" — "Вывало наговорю с три короба, а душа у меня тонкая, ранимая... Вот и отравлю собеседника..." (разжовываю — то есть обосновываем свои проблемы чем угодно кроме недостатков в себе... до разжовываю — в себе, в данном случае нужно спроецировать на свои любимые игрушки).

Так вот есть куча ОпенСорсов с документацией и т.п. И не фига перекладывать с больной головы на здоровую.

ЗЫ

Смайлик в конце предложения означет "Шутка" или сарказм.

ЗЗЫ

Приношу извинения, что сразу не разжувал мысль.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: минусы Ruby
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.06.06 16:00
Оценка: :)
Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>А Smalltalk, к примеру, — противоречит?


А ты его среды видел? Все через одно место.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: минусы Ruby
От: Mamut Швеция http://dmitriid.com
Дата: 02.06.06 06:34
Оценка: +1
E>>Скорее наоборот -- люди пользуются Руби, им незачем кому-то что-то доказывать.

VD>Ага. Оно и видно. Один пользуется, а рассуждений о Руби как будто на нем все пишут.


Справедливости ради замечу, что интерес к Руби в интернете растет.
... << RSDN@Home 1.2.0 alpha rev. 647>>


dmitriid.comGitHubLinkedIn
Re[9]: минусы Ruby
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 03.06.06 04:50
Оценка: +1
Здравствуйте, VladD2, Вы писали:

E>>Ничего. Просто говорю, что если для тебя привычным и логичным является ToString, то точно так же для других привычным и логичным является to_s.


VD>Не, не. Не в коем случае не стоит смешивать эти два понятия — "привычное" и "логичное". ToString не является для меня привычным. Но он является для меня логичным. Более того обоснование того почему он так назван, а не к примеру, itoa или to_s, я считаю зравыми, а цели полезными. Потому я называю тех кто борется с этим аргументируя откровенно полхой подход привычками — маргиналами.


Это больше похоже на неприятие точек зрения, отличных от твоей.

VD>Именно по этому я прекрасно понимаю Зверька когда он рассказывает о том, что хорошего он нашел в Руби, и не понимаю тебя, когда ты доказывашь, что плохое в Руби — это на самом деле нормально.


E>>Поскольку предназначены для одного и того же и имена логически вычисляются: to (действие) + имя типа.


VD>Прости, ты прикидывашся или для тебя s — это нормальное имя типа?


Да, после нескольких недель программирования на Ruby это имя совершенно нормальное.

E>> В Ruby имя типа обозначается короче.


VD>Я еще бы поколебался если бы название было to_str. Тут уже действительно понятно о чем речь, в общем-то, и нужно быть немного пижоном, чтобы ассоциировать str со struts, например. Но считать нормальным однобуквенное имя типа!!! Увольте.


Ты будешь долго смеяться, но to_str так же есть. Чаще всего это синоним для to_s, но не всегда.

VD>Так вот я понял бы, что значит str, но я так же понимаю почему это плохо. Люди стремятся к единообразию и если допустить str в публичном интерфейсе, то завтра появится def для обозначения defaulte, а после завтра появится ajd_to_jd... и пошло, поехало. В итоге вместо кода получается шифровка. Добавляем к ней случайные опечатки в именах переменных (мы и это считаем мелочами) и вот уже на горизонте мы видим результат который без пол литра не понять.


Это фобия.
Есть другое, более логичное правило -- наиболее часто используемые методы/идентификаторы с четко и давно определенной семантикой делаются наиболее короткими (to_s, to_i, to_f, eql?). А редко используемые или неоднозначно трактуемые -- длинными (assert_nothing_raised). Этакий код Хавмана. И, главное, на выходе получается читабельный и сопровождаемый код.

E>>Так вот, я так же не знаю, что такое Astronomical Julian Day, поэтому метод ajd_to_jd мне на фиг не упал. А если бы он был мне нужен, то имя ajd_to_jd было бы для меня абсолютно понятным.


VD>Серьезно? Тогда понятно. Конечно если не знать английский на таком уровне, то разница между "а" и "Астрономическое" действительно не очевидна.


Не понял шутки юмора. Метод ajd_to_jd существует не сам по себе, а в классе Date. Что сразу же сужает возможность трактования "a" в ajd_to_jd как Astronomical.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[13]: минусы Ruby
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 04.06.06 06:25
Оценка: +1
Здравствуйте, VladD2, Вы писали:

E>>И я сильно сомневаюсь, что количество информационных ресурсов, на которых упоминается C# больше, чем тех, на которых упоминается C.


VD>1. Количество упоминаний С посчитать практически невозможно, так как это просто буква алфавита. Даже C# тяжело, так как это в общем-то нота. Ява это еще по совместительству кофе, мотоциклы, остров и даже среда выполнения.


У них написано, что они делают поиск по

+"<language> programming"


VD>2. Измерять популярность языков можно только посчитав количество активно программирующих на них людей или количество развиваемых на них проектов.


С этим так же все кореллируется. На SourceForge самое большое количество проектов на Java, C++ и C (что-то порядка 16000 на каждого). И, насколько я помню, долгое время лидером был как раз C, затем его опередил C++, а затем Java обогнал C++. Статистика TIOBE показывает то же самое -- популярность C++ и Java растет, C -- снижается.

VD>3. С уже лет 10 как явно проигрывает по популярности С++. Это как минимум. И если кто-то говорит обратно, то его остальные выводы вызвают огромные сомнения.


Может быть под Windows так и есть, но вот про Unix я бы не стал так говорить.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[15]: минусы Ruby
От: FR  
Дата: 04.06.06 15:04
Оценка: +1
Здравствуйте, VladD2, Вы писали:


VD>По-моему значительно понятнее. Не нужно объяснять что такое m[1], to_i и т.п. Вот только регексы конечно ужасны и портят всю картину.


В этом вопросе я скорее ближе к твоей позиции чем к позиции eao197, но его код (не смотря на птичий для меня синтаксис руби) понятнее чем твой.
Re[17]: минусы Ruby
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 05.06.06 04:07
Оценка: :)
Здравствуйте, VladD2, Вы писали:

VD>Сори, плюс ФР-у я так понимаю, можно рассаматривать как изменение позиции?


С чего ты взял? Ведь FR сказал, что мой код ему понятнее, чем твой. С этим то я и согласился.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[17]: минусы Ruby
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 05.06.06 05:02
Оценка: +1
Здравствуйте, VladD2, Вы писали:

E>>Если чесно, мне по барабану, является ли <a> в HTML халтурой или нет. Но, когда мне приходится генерировать HTML из программы, мне удобно пользоваться в программе такими же понятиями, как и в HTML. Это можно назвать приближением к предметной области.


VD>Ну, если из контекста ясно, что речь идет о теге. Например:

VD>
VD>EmitTeg.a(...)
VD>

VD>то я не против. Но в случае Руби речь то не о том. Тут именно что сокращения ради урощения вбивания текста.

Ага, уже прогресс, уже учитывается влияние контекста. Чтобы развить тему скажу, что в динамических языках не смотря на отсутствие явно декларируемых типов переменных и продвинутых IDE с автокомплитом ошибок типизации или не правильного использования объектов очень мало. И объясняется этот парадокс тем, что в локальном, небольшом контексте все намерения программиста очевидны и допустить ошибку тяжело. А контексты получаются небольшими именно благодоря принципам code less и DRY.

Вот ты, например, прицепился к нескольким методам, в частности к CGI::HtmlExtension.a(). А ведь использование методов из модуля CGI настолько очевидно, что проблем с короткими именами просто нет:
require "cgi"
cgi = CGI.new("html4")

cgi.out do
  cgi.html do
    cgi.body do
      cgi.h1 {  "Hello Again, " }  +
      cgi.b {  cgi['name']}
    end
  end
end

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

E>>Окружающих Ruby программистов или просто окружающих? Если просто окружающих, то они идут лесом.


VD>Я правильно понимаю, что Руби-программисты это отдельная каста? Мне не нравятся касты. Особенно если для вхождения в оную нужно забить голову заучиванием невнятных идетификаторов.


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

VD>А чтобы знать что означает что нужно в голове создать хэш-табчичку и запоминать i -> integer, s-> string, tr -> ???... Сори у меня уже хэш испортился.


E>>Название имеет смысл для Ruby программистов, т.к. IO -- это один из базовых классов в Ruby для организации ввода вывода. Поэтому to_io (или ToIO) означает, что объект может сконвертироваться в реализацию класса IO. В C++ это было бы аналогом возвращения объекта std::iostream.


VD>Вот iostream, хотя лучше io_stream или IO.Stream, ну, да не важно, так вот iostream смысл имеет, а to_io — это снова в хэш-табличку.


Когда ты изучаешь какой-то язык, например, английский, ты должен заучить правила использования артиклей a и the. А к ним еще и перечень исключений. Это считается нормальным процессом. А там хэш-табличка должна быть поболее.
Когда мы изучаем конкретный язык программирования, то так же должны привыкнуть к правилам языка. Например, о необходимости боксинга int в Integer в Java, или о наличии и правилах использования IDisposable в .Net. Кроме того, когда мы пишем свою программу, мы должны составлять свою хеш-табличку понятий, которыми оперирует программа. Это все естественный процесс. И запомнить несколько простых соглашений в Ruby страшно только тем, кто просто о Ruby трепиться.

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


VD>Серьезное знание. А для того чтобы понять, что "m" у тебя некий массив mach-ей знания не требуются?


Требуются. Для того, чтобы понять приведенные примеры нужно знать особенности парсинга Regexp-в в каждом из языков. К этом я и вел. Что когда знаешь принцип работы Regexp#match в Ruby, то мой пример тривиален. Так же, как и зная принцип парсинга Regexp-ов в Nemerle.

E>>А ты придумай для tr и tr_s внятные имена


VD>Не надо вопросом на вопрос. А то ведь тяжело придумть не зная что придумывать.


Я к тому, что ты лихо разбрасываешься ярлыками, а если взяться за задачу серьезнее, то окажется, что не так уж и просто ее решить лучше. Вот описания методов tr и tr_s:

str.tr(from_str, to_str) => new_str

Returns a copy of str with the characters in from_str replaced by the corresponding characters in to_str. If to_str is shorter than from_str, it is padded with its last character. Both strings may use the c1—c2 notation to denote ranges of characters, and from_str may start with a ^, which denotes all characters except those listed.

   "hello".tr('aeiou', '*')    #=> "h*ll*"
   "hello".tr('^aeiou', '*')   #=> "*e**o"
   "hello".tr('el', 'ip')      #=> "hippo"
   "hello".tr('a-y', 'b-z')    #=> "ifmmp"


str.tr_s(from_str, to_str) => new_str

Processes a copy of str as described under String#tr, then removes duplicate characters in regions that were affected by the translation.

   "hello".tr_s('l', 'r')     #=> "hero"
   "hello".tr_s('el', '*')    #=> "h*o"
   "hello".tr_s('el', 'hx')   #=> "hhxo"

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

Кстати, в Qt есть глобальная функция tr(), она используется для локализации сообщений приложения. С точки зрения хорошего стиля ее имя ужасно и недопустимо. Но на практике она очень удобно. Что говорит о том, что теория должна подтверждаться практикой. И если это не так, то теория не верная.

E>>sub, rjust, ljust -- понятны без проблем.


VD>Серьезно? А я вот думал, что sub — это пропрограмма. Ну, привык я в Васике к этому. А что значит остальное хоть убей не понимаю.


Видно с обработкой текста мало работал. Да и не обратил внимания на то, это это методы String-а.
sub -- substitute
rjust -- right justify
ljust -- left justify

E>> Но remove_trailing_separators вместо chomp, имхо, это так же не есть хорошо.


VD>Но можно что-то вроде ЧомпЧтоТоТам...


Имхо, лучше уж chomp.

А вообще приходит аналогия с ассемблером IBM 360 (и наших больших ЕС ЭВМ). Там наиболее распространенные команды вообще однобуквенные были. И при том ассемблер был очень простой и логичный, а писать на нем было приятнее чем даже на x86 ассемблере.

E>>По моему, они эквивалентны.


VD>Серьезно?


Абсолютно.

E>> При том, что название HexStrToIntStr имеет такую же смысловую нагрузку, что и to_i(16).to_s.


VD>Правда? А я провел двадцать минут в интернете чтобы понять что же делает to_i(16). Да и не просто из алгоритма вычленить суть. Все же английский понятнее. Не находишь?


Еще раз повторю, что для Ruby программиста понять, что делает to_i(16) не составляет труда.

VD>>>Ну, а то что коротких имен можно в строку больше запихать,


E>>Об этом, насколько я помню, не было и речи. Цель не в том, чтобы в одной строке было больше идентификаторов.


VD>Зачем? Не станет же код проще от этого?


E>> А в том, чтобы было меньше строк.


VD>Где? В фунции или во всей программе?


E>> А в строке -- меньше идентификаторов.


VD>Это как-то входит в противоречие с идеей запихать в одну строку больше функций. Не находишь?


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

E>>Видишь ли, код Хаффмана ценен тем, что он не теряет информации. Совсем. Он только позволяет записать ее компактнее.


VD>А я вижу что теряет. На чтение твоего кода у меня уходит больше времени.


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



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



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

Внутренняя ошибка сервера

URL: /Forum/Private/Rate.aspx?mid=1937925&rate=-4

Unable to cast object of type 'System.Collections.Hashtable' to type 'System.Type'.

support@rsdn.ru

А еще день назад было не менее занимательное сообщение о том, что Int32 has no default constructor (кажется так, но окно быстро захлопнулось, не успел скопипастить).

Так что IDE и статически типизированные языки действительно рулят.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[12]: минусы Ruby
От: Mamut Швеция http://dmitriid.com
Дата: 05.06.06 06:31
Оценка: +1
E>На конференции RubyConf2005 был доклад Akira Tanaka "open-uri, Easy-to-Use and Extensible Virtual File System", в котором особое место отводится тому, как проектировать Easy-to-Use API. Вот некоторые цитаты со слайдов доклада:
E>

E>Huffman coding
E>* Shorter for frequent things
E>* Longer for rare things
E>Optimize for frequent things.
E>Ex: p (пример с использованием метода Kernel#p, который печатает результат вызова у объекта метода inspect)
E>



E>Ex: p
E>
E>p obj
E>

E>* Very frequent use
E>* Bad name in common sence
E>* Almost no problem because everyone knows
E>

E>Ex: pp and y (примеры с методами pp (pretty printer) и y (преобразование в YAML))
E>* Bad name in common sence
E>* Problematic than p because not everyone knows.



Тут я позволю себе не согласиться с фразой "Almost no problem because everyone knows". Для начинающего изучать все эти рр, р и y — это абракадабра. Если у того же p есть alias в стиле print_method_result, то тогда нормально, а так — Такое впечтление, что ведется наивная попытка ускорить интерпретатор, передавая ему меньше текста для разбора
... << RSDN@Home 1.2.0 alpha rev. 647>>


dmitriid.comGitHubLinkedIn
Re[7]: минусы Ruby
От: mogadanez Чехия  
Дата: 01.08.06 12:37
Оценка: +1
VD>Вопрос настолько неразумен, что я даже теряюсь. ToString полностью описывает смысл метода. А вот что значит to_s можно толко запомнить. Запомнить один to_s может и можно. Но таких вот сокращений в Руби пруд пруди.

для тебя это так — потому что ты с ним долго жил,
а вообще метод ToString следовало бы назвать ConvertToString — оно еще более логично.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Re[15]: минусы Ruby
От: mogadanez Чехия  
Дата: 01.08.06 16:07
Оценка: -1
VD>Мля. Еще однин миф. Ребатки. Линукс можно заметить невооруженным взглядом только в веб-решениях. Виндовс — это большая часть рынка. И именно потому большинство коммерческих контор работают на Виндовс. Другие ОС (т.е. не Виндовс и не Линукс) вообще видно только в микроскоп. Людям нужны стандарты и выбор ПО, а не трах с диковинными ОС. Так что если вы попали в пару процентов у которых заказчика кровь из носу нужны диковинные ОС или даже Линукс, то воспринимайте это адекватно, а не как будто Виндовс это одна из диковенных ОС.


Ты что с луны свалился? про Apple слышал когда нибудь? если ты на нем не работаешь это ни о чем не говорит, у нас в оффисе соотношение Win и Mac ~ 10 к 8

у многих наших клиентов вообще подавляющее засилие Mac'ов
Re[10]: минусы Ruby
От: WolfHound  
Дата: 01.08.06 16:59
Оценка: +1
Здравствуйте, mogadanez, Вы писали:

M>а почему тогда в том же немерле def означает define?

M>почему сократили? почему не полностью define? ведь если я первый раз вижу код на немерле и не писал на языках где есть def, я могу и с default перепутать, или с defolt

M>такая же фигня с параметром "_" — человек первый раз видящий его хрен догадается что он значит.

Ну ты блин сравнил... два сокращения с сотнями...
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[8]: минусы Ruby
От: Sinclair Россия https://github.com/evilguest/
Дата: 02.08.06 10:57
Оценка: :)
Здравствуйте, mogadanez, Вы писали:
M>для тебя это так — потому что ты с ним долго жил,
M>а вообще метод ToString следовало бы назвать ConvertToString — оно еще более логично.
RTFM Convert.ToString
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[11]: минусы Ruby
От: mogadanez Чехия  
Дата: 02.08.06 13:08
Оценка: -1
M>>ведь если я первый раз вижу код на немерле и не писал на языках где есть def, я могу и с default перепутать, или с defolt
VK>Я тебе не верю. Надо обладать невероятной степенью тупизны, чтобы не понять с первого взгляда что означает def в коде на Nemerle.

я тоже самое могу сказать про to_s

M>>такая же фигня с параметром "_" — человек первый раз видящий его хрен догадается что он значит.

VK>Тоже не верю. "_" выглядит очень интуитивно понятно, особенно в match выражениях. Кроме того "_" это очень распространенная идиома. Я например имел о ней представление задолго до знакомства с Nemerle, из Пролога, SML, Haskell. В Nemerle правда "_" еще используется для конструирования лямбда-выражений с безымянными аргументами, но даже в этом случае я был знаком с чем-то приблизительно похожим, а именно с boost::lambda.

интутивно понятно потому что знал? Я не знал, и мне понятно не было — прочитал теперь понятно. зато я интуитивно понял что такое to_int(16) — хотя другие потратили полчаса на поиск в интернете.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Re[12]: минусы Ruby
От: Vermicious Knid  
Дата: 02.08.06 13:46
Оценка: +1
Здравствуйте, mogadanez, Вы писали:

M>интутивно понятно потому что знал?

Нет, потому что это действительно интуитивно понятно. Я помню когда изучал Пролог(а это первый язык в котором я встретил паттерн "_"), то "_" это одна из немногих вещей, не вызвавших абсолютно никаких трудностей в понимании. То есть из кода было прекрасно понятно для чего "_" используется, я даже не помню чтобы я читал какое-то объяснение смысла этой "загадочной" конструкции.

M>Я не знал, и мне понятно не было — прочитал теперь понятно.

Не могу себе этого представить. Ну что может быть в нем непонятного? Например здесь:
beers(n : int) : string {
  | 0 => "no more bottles of beer"
  | 1 => "1 more bottle of beer"
  | _ => $"$n bottles of beer"
}

M>зато я интуитивно понял что такое to_int(16) — хотя другие потратили полчаса на поиск в интернете.
Я кстати не верю и в то, что VladD2 не понял что такое to_int(16), хотя с его тезисами отчасти согласен. По-моему для любого человека, прошедшего "школу" libc, с его функциями вроде strtol и atoi, понять что-то подобное будет крайне легко.
Re[14]: минусы Ruby
От: Klapaucius  
Дата: 04.08.06 07:02
Оценка: +1
Здравствуйте, Mamut, Вы писали:

M>>>Я не знал, и мне понятно не было — прочитал теперь понятно.

VK>>Не могу себе этого представить. Ну что может быть в нем непонятного? Например здесь:
VK>>
VK>>beers(n : int) : string {
VK>>  | 0 => "no more bottles of beer"
VK>>  | 1 => "1 more bottle of beer"
VK>>  | _ => $"$n bottles of beer"
VK>>}
VK>>


M>Для человека, незнакомого с pattern-matching'ом, здесь непонятно все


По моему скромному разумению, такие средства как pattern-matching или там list comprehentions как раз и делают код (за исключением особо навороченных случаев) понятным любому человеку изучавшему алгебру в школе. Собственно говоря, человек, увидивший пример с pattern-matching — уже в какой-то степени знаком с pattern-matching.

Вот что, например, непонятного здесь:
fac 0 = 1
fac n = n * fac (n-1)


Или здесь:
fac n = product [1..n]
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re: Возвращаясь к вопросу :)
От: Cyberax Марс  
Дата: 07.11.07 11:18
Оценка: +1
Здравствуйте, Left2, Вы писали:

L>Вообщем, моё мнение — если target-платформа ограничена Windows, то использование WScript очень даже себя оправдывает.

Я как-то очень долго искал как работать из WScript с файлом в бинарном режиме. Ответ: НИКАК.

Вообще, я для больших скриптов использую Python — в нем намного более удобная работа с файлами и каталогами, чем через FSO.
Sapienti sat!
минусы Ruby
От: Курилка Россия http://kirya.narod.ru/
Дата: 28.05.06 09:41
Оценка:
Собственно хотел предложить для прочтения (и обсуждения тоже) статью 5 things I hate about Ruby
Особенно не положительным 4-й пункт кажется: навязываемый "Ruby Way", который ещё и не имеет однозначной трактовки.
З.Ы. Как-то не нашёл куда логичнее будет это написать: руби почти насквозь императивный, поэтому в декларативные не лезет, а среди языков его нет...
Re[2]: минусы Ruby
От: Cyberax Марс  
Дата: 28.05.06 13:49
Оценка:
eao197 wrote:
> c) обработка C++ исходников с целью поиска #include-зависимостей (в
> Mxx_ru используется написанный на Ruby вариант). Парсинг тысяч исходных
> файлов объемом в десятки килобайт так же серьезно нагружает дисковую
> подсистему. И при этом скорость Ruby скрипта все равно оказывается
> нормальной для повседневного использования.
Рекомендую добавить в mxx_ru кэш зависимостей include'ов — на ноутах с
медленным винтом значительно помогает.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[3]: минусы Ruby
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 28.05.06 15:24
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Рекомендую добавить в mxx_ru кэш зависимостей include'ов — на ноутах с

C>медленным винтом значительно помогает.

Да, это в планах. Как и еще целая куча фич


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[3]: минусы Ruby
От: Андрей Хропов Россия  
Дата: 28.05.06 17:38
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Прочтя этот ответ я понял, осознал главную причину по которой нельзя использовать Руби в серьезных проектах. "это же OpenSource со всеми вытекающими" А вытекающие кривизна.

Я думаю "За и против OpenSource" — это отдельная СВ. Давай здесь только про Руби.

P.S. Nemerle — это тоже Open source .
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[2]: минусы Ruby
От: Курилка Россия http://kirya.narod.ru/
Дата: 29.05.06 13:02
Оценка:
Здравствуйте, eao197, Вы писали:

E>С другой стороны, как и с другими возможностями Ruby, метапрограммированием не сложно злоупотребить и превратить программу в головоломку. А поскольку язык здесь не ставит перед программистом никаких барьеров, то приходиться уповать на здравый смысл программиста. Но, как было упомянуто выше, далеко не всегда это возможно.


Ага, вот благодаря этому рождаются такие вещи — круто, конечно, что можно такие фичи реализовать, но имхо результат получается довольно странный и не руби и не лисп (или хаскел для паттерн-мэтчинга) — нечто странное
Re[2]: минусы Ruby
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.06.06 01:59
Оценка:
Здравствуйте, eao197, Вы писали:

E>Собственно, со статьей-то уже все понятно.


А что понятно? Мужик в общем-то прав по всем пунктам. Как раз твоя позиция выглядит более предвзятой.

На счет того, что я ругаю Руби — это не правда. Я ругаю необоснованную его рекламу. А основными недостатками языка являются тормоза, отсуствие полноценной IDE (комплит, рефакториг, ...), отсутствие статической типизации, черезмерная экономия на длинне идентификаторов в стандартной библиотеке, отсуствие декларации переменных, чреватые рнтайм-ошибками приведения типов, текстуальность метарасширений. А сам язык как раз очень ничего. По крайней мере по сравнению с Питомном или ДжиХрипом он мне больше нравится.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: минусы Ruby
От: Cyberax Марс  
Дата: 01.06.06 03:46
Оценка:
VladD2 wrote:
> На счет того, что я ругаю Руби — это не правда. Я ругаю необоснованную
> его рекламу. А основными недостатками языка являются тормоза, отсуствие
> полноценной IDE (комплит, рефакториг, ...)
А у Немерля уже есть IDE? А как там с рефакторингом? А почему медленнее
С++ работает?

> отсутствие статической типизации

А это не минус. Это огромный плюс в тех задачах, где Ruby используется.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[3]: минусы Ruby
От: Kluev  
Дата: 01.06.06 06:00
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, eao197, Вы писали:


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

А что длжно быть как в винде?
DoSomethingByLeftHandEatShitAndDie
Re[4]: минусы Ruby
От: Cyberax Марс  
Дата: 01.06.06 06:06
Оценка:
Kluev wrote:
> черезмерная экономия на длинне идентификаторов в стандартной библиотеке,
> отсуствие декларации переменных,
> А что длжно быть как в винде?
> DoSomethingByLeftHandEatShitAndDie
AccessCheckByTypeResultListAndAuditAlarmByHandle
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[4]: минусы Ruby
От: Mamut Швеция http://dmitriid.com
Дата: 01.06.06 06:43
Оценка:
VD>>отсуствие полноценной IDE (комплит, рефакториг, ...),

E>Да есть IDE для Ruby, как open-source (FreeRDE, Mongrel, RDT), так и коммерческие (Komodo).

E>Более того, Rubyist-ов совсем это не парит. Большинство используют VIM, emacs и TextMate (под MacOS), не испытывая при этом никаких сожалений.

Есть еще коммерческий TextMate для MacOS
... << RSDN@Home 1.2.0 alpha rev. 647>>


dmitriid.comGitHubLinkedIn
Re[5]: минусы Ruby
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 01.06.06 06:47
Оценка:
Здравствуйте, Mamut, Вы писали:

E>>Более того, Rubyist-ов совсем это не парит. Большинство используют VIM, emacs и TextMate (под MacOS), не испытывая при этом никаких сожалений.


M>Есть еще коммерческий TextMate для MacOS


Так я же его указал
Живьем его не видел, но по роликам -- классная штука. Хотя, имхо, это не IDE, а продвинутый программерский редактор.

Кстати, для RubyOnRails на основе Eclipse делают IDE: RadRails


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[6]: минусы Ruby
От: Mamut Швеция http://dmitriid.com
Дата: 01.06.06 06:54
Оценка:
E>>>Более того, Rubyist-ов совсем это не парит. Большинство используют VIM, emacs и TextMate (под MacOS), не испытывая при этом никаких сожалений.

M>>Есть еще коммерческий TextMate для MacOS


E>Так я же его указал




E>Живьем его не видел, но по роликам -- классная штука. Хотя, имхо, это не IDE, а продвинутый программерский редактор.


Эххх... Часто именно такого продвинутого редактора и не хватает.

E>Кстати, для RubyOnRails на основе Eclipse делают IDE: RadRails


Пользуюсь, не нравится Хотя под винду лучше и нет (сейчас качаю триал Комодо, посмотрю, что там).
... << RSDN@Home 1.2.0 alpha rev. 647>>


dmitriid.comGitHubLinkedIn
Re[5]: минусы Ruby
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 01.06.06 06:57
Оценка:
Здравствуйте, Mamut, Вы писали:

M>Есть еще коммерческий TextMate для MacOS


Еще IDE: Arachno Ruby (платная), Ruby Development Environment.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[7]: минусы Ruby
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 01.06.06 07:26
Оценка:
Здравствуйте, Mamut, Вы писали:

E>>Живьем его не видел, но по роликам -- классная штука. Хотя, имхо, это не IDE, а продвинутый программерский редактор.


M>Эххх... Часто именно такого продвинутого редактора и не хватает.


Насколько я понял, он работает по принципу изначально заданных сокращений. Т.е. ftg раскрывается в form_tag с какой-нибудь шаблонной лабудой. Такие штуки в vim через abbreviations можно сделать.
К тому же в VIM 7 добавили более продвинутый механизм поиска соответствий (completion и omni-completion). Omni-completion работает на основе интерпритации ruby-кода и глючит в настоящее время, а вот обычный completion (через ^X^N, ^X^P и ^N) работает для Ruby, имхо, круче, поскольку ищет названия и в содержимом библиотек Ruby (через RUBYLIB).


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[8]: минусы Ruby
От: Mamut Швеция http://dmitriid.com
Дата: 01.06.06 07:40
Оценка:
M>>Эххх... Часто именно такого продвинутого редактора и не хватает.

E>Насколько я понял, он работает по принципу изначально заданных сокращений. Т.е. ftg раскрывается в form_tag с какой-нибудь шаблонной лабудой. Такие штуки в vim через abbreviations можно сделать.

E>К тому же в VIM 7 добавили более продвинутый механизм поиска соответствий (completion и omni-completion). Omni-completion работает на основе интерпритации ruby-кода и глючит в настоящее время, а вот обычный completion (через ^X^N, ^X^P и ^N) работает для Ruby, имхо, круче, поскольку ищет названия и в содержимом библиотек Ruby (через RUBYLIB).


Эээ нет Я тут emacs до конца не осилил, а вы ко мне с vim'ом
... << RSDN@Home 1.2.0 alpha rev. 647>>


dmitriid.comGitHubLinkedIn
Re[9]: минусы Ruby
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 01.06.06 07:54
Оценка:
Здравствуйте, Mamut, Вы писали:

M>Эээ нет Я тут emacs до конца не осилил, а вы ко мне с vim'ом


vim проще.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[10]: минусы Ruby
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 01.06.06 08:48
Оценка:
Здравствуйте, eao197, Вы писали:

E>Здравствуйте, Mamut, Вы писали:


M>>Эээ нет Я тут emacs до конца не осилил, а вы ко мне с vim'ом


E>vim проще.


но в нём нет gnus-а
http://www.smalltalk.ru | << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[2]: минусы Ruby
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 01.06.06 09:36
Оценка:
Здравствуйте, eao197, Вы писали:

E>3. Ruby's "official" documentation is sparse and, in some cases, nonexistent.


В качестве доказательства, что ситуация с документацией меняется в лучшую сторону прямо на глазах -- открыт новый сайт http://www.rubymanual.org.
Искать информацию о классах и методах можно прямо через URL, например, о методе 'open': http://www.rubymanual.org/open


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[3]: минусы Ruby
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 01.06.06 09:41
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Я ругаю необоснованную его рекламу.


А, понял! Необоснованная реклама -- это, например, то, что заглавной темой нового номера Linux Journal является Ruby и Rails



SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[8]: минусы Ruby
От: Mamut Швеция http://dmitriid.com
Дата: 01.06.06 13:55
Оценка:
E>>>Кстати, для RubyOnRails на основе Eclipse делают IDE: RadRails

M>>Пользуюсь, не нравится Хотя под винду лучше и нет (сейчас качаю триал Комодо, посмотрю, что там).


ЗХ>А ты таки стал писать на Ruby?


Я таки взялся за RoR Пока ковыряюсь

ЗХ>Тогда подпишись на ruby-talk


Это где?
... << RSDN@Home 1.2.0 alpha rev. 647>>


dmitriid.comGitHubLinkedIn
Re[4]: минусы Ruby
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.06.06 15:00
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>А у Немерля уже есть IDE?


Есть. Пока что она в стадии разработки, но все же формы уже кое как дизайнятся и комплит на подходе. Если учесть, что это есть уже на стадии когда компилятор то до конца не отлажен, то очевидно, что это уже больше чем в Руби. А главное, язык идеологически не противоречит ни поддержке разных интелисенсов, ни рефакторингу.

C>А как там с рефакторингом?


Будет в течении месяца или двух.

C> А почему медленнее С++ работает?


Кто тебе такую глупость сказал?

>> отсутствие статической типизации

C>А это не минус. Это огромный плюс в тех задачах, где Ruby используется.

Это огромный минус в любых задачах. Это дополнительная нагрузка на програмиста, основной источник тормозов и главное, припятствие тех самых фич автоматизации (комплит ворда, рефакторинга, ...) Другое дело, что за счет динамичности Руби позволяет иногда халтурить и добиваться результата несколько проще. Однако, как мы видим, тот же Немреле позволяет добиваться того же не теряя приемуществ статической типизации.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: минусы Ruby
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.06.06 15:00
Оценка:
Здравствуйте, Kluev, Вы писали:

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


K>А что длжно быть как в винде?

K>
DoSomethingByLeftHandEatShitAndDie


Обрати внимание, что МС и Сан пришли в итоге к выводу, что именование должно быть понятным и заноченым. А однобуквенных сокращений вообще быть в публичном интерфейсе не должно.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: минусы Ruby
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 01.06.06 15:21
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Громких криков о Руби лично от одного тебя здесь выше крышы,


Хорошо, буду кричать потише

VD>а флэймов нет толко потому, что Руби этот интересует основную аудиторию в основном теоритически.


Скорее наоборот -- люди пользуются Руби, им незачем кому-то что-то доказывать.

E>> (ссылки сейчас искать некогда, но в Философии была тема про скорость импорта в БД данных из гигабайтных логов программой, написанной на F#; в Средствах разработки dmz сравнивал скорость парсинга логов на Python и Perl, туда же было добавлено сравнение с Ruby; в исходниках лежит мой проект svn-dumper-loader -- там svn dump на 160Mb репозитории работает минуту, а затем две минуты dump-файл архивируется bzip2, при таких показателях сам Ruby скрипт просто летает).


VD>Я знаю как еще ускорить покажатели Руби. Надо после архивации произвести проверку архивов. А дамп конечно лучше парсить С++-ной программой вызваемой из скрипта. От тода Руби будет рулить по страшному. Правда при этом он превратится в замену скрипту шела, но гордиться все равно есть чем.


Ты хоть понял о чем сказал?
Попробуй внятно объяснить, в чем будет преимущество Nemerle или C# при решении задачи svn-dumper-loader-а
Автор: eao197
Дата: 29.05.06
.

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


VD>Это недостаток личо для меня основной. А то что этот недостаток ставит крест не на одном Руби, а на целом классе языков, так это не мои проблемы.


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

VD>А что ты вообще замечал? Ты пользушся средствами разработки на уровне 70-ых готов прошлого века. От того тебя радует даже минимум. Ну, по думашь там to_s что-то назвали? Фигня... Сделем из своей головы огромный хэш-мап и будет ассоциировать эти to_s в tt_string. За то каждая строчка на 5-7 симвлово короче. Это же главное! Не правда ли?


А разве тот же хэш мап не должен использоваться для запоминания ToString? А если ты знаешь, что метод преобразования в строку есть, то не все ли равно, называется ли он ToString или to_s?

E>>Какие из них ты считаешь черезмерно сокращенными?


VD>Большей частью те что остались за кадром (видмо намеренно). Например, to_s. Но и из приведенных примеров перлов можно недергать не мало. Например, ajd_to_jd меня очень радует. Видимо метод преобразует Албанского Джона Дудаева в еще кого-то странного.


Тебе бы было понятнее, если бы он назывался ConvertAstronomicalJulianDayNumberToJulianDayNumber? Тогда давай ты сразу, с ходу, без обращения к справочникам объяснишь, чем отличается Astronomical Juluan Day от Julian Day.



А вообще спасибо за смешной ответ. Читать было весело.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[5]: минусы Ruby
От: Зверёк Харьковский  
Дата: 01.06.06 15:31
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Cyberax, Вы писали:


C>>А у Немерля уже есть IDE?


VD>Есть. Пока что она в стадии разработки, но все же формы уже кое как дизайнятся и комплит на подходе. Если учесть, что это есть уже на стадии когда компилятор то до конца не отлажен, то очевидно, что это уже больше чем в Руби.

Правда?
Автор: Зверёк Харьковский
Дата: 01.06.06


VD>А главное, язык идеологически не противоречит ни поддержке разных интелисенсов, ни рефакторингу.


А Smalltalk, к примеру, — противоречит?
FAQ — це мiй ай-кью!
Re[6]: минусы Ruby
От: VladGalkin Украина  
Дата: 01.06.06 15:32
Оценка:
Здравствуйте, Зверёк Харьковский, Вы писали:


ЗХ>А Smalltalk, к примеру, — противоречит?


Хм, наверное противоречит, только вот почему то Smalltalk IDE это очень круто.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
ДЭ!
Re[7]: минусы Ruby
От: VladGalkin Украина  
Дата: 01.06.06 16:06
Оценка:
Здравствуйте, VladD2, Вы писали:


VD>А ты его среды видел? Все через одно место.


Ну это уже даже не смешно... Многим средам ещё ..ать и ..ать до сред Smalltalk, из которых, собственно, современные IDE и пошли.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
ДЭ!
Re[10]: минусы Ruby
От: CrazyPit  
Дата: 01.06.06 19:20
Оценка:
Здравствуйте, eao197, Вы писали:

E>Здравствуйте, Mamut, Вы писали:


M>>Эээ нет Я тут emacs до конца не осилил, а вы ко мне с vim'ом


E>vim проще.


Emacs функциональнее
Re[7]: минусы Ruby
От: CrazyPit  
Дата: 01.06.06 19:45
Оценка:
Здравствуйте, VladGalkin, Вы писали:

VG>Здравствуйте, Зверёк Харьковский, Вы писали:



ЗХ>>А Smalltalk, к примеру, — противоречит?


VG>Хм, наверное противоречит, только вот почему то Smalltalk IDE это очень круто.


Ага. А ещё SLIME и комерческие IDE для CL'a тоже весьма продвинуты. Так что минимум для двух динамических языков есть очень хорошие IDE.
Re[10]: минусы Ruby
От: Left2 Украина  
Дата: 02.06.06 10:40
Оценка:
K>И чего же удобного?
Удобно — по сравнению с bat-файлами. Удобно человеческим синтаксисом, опять же тем что можно писать сколь угодно сложную логику.

K>все сделано через ж-пу.

K>Чтобы банальные вещи в файловой системе сделать надо FileSystemObject создавать.

Ну да, надо. Это ж JavaScript — язык общего назначения, не привязанный вообщем-то к ОС. Было бы странно если бы работа с файлами была бы туда встроена.

K>вот bash это действительно удобная альтерантива бат-файлам.


Да Бога ради — я не возражаю что есть куда более удобные специализированные средства. Но тут есть возможность писать на языке который понимают 90% программистов, к тому же ничего не нужно доставлять в систему (имеется в виду Windows). ну и плюс к этому — бенефиты типа того что можно делать всё для чего есть COM-обьекты — лазить в интернет (MS XML Parser), создавать отчёты в том же Excel, и т.д. и т.п.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[11]: минусы Ruby
От: Cyberax Марс  
Дата: 02.06.06 10:42
Оценка:
Left2 wrote:
> Да Бога ради — я не возражаю что есть куда более удобные
> специализированные средства. Но тут есть возможность писать на языке
> который понимают 90% программистов, к тому же ничего не нужно доставлять
> в систему (имеется в виду Windows). ну и плюс к этому — бенефиты типа
> того что можно делать всё для чего есть COM-обьекты — лазить в интернет
> (MS XML Parser), создавать отчёты в том же Excel, и т.д. и т.п.
Вот кто бы рассказал мне как на JS работать с бинарными файлами
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[12]: минусы Ruby
От: Left2 Украина  
Дата: 02.06.06 10:49
Оценка:
C>Вот кто бы рассказал мне как на JS работать с бинарными файлами

Ага, а ещё как числобробилки на нём писать
А ежели серьёзно — вроде бы можно через ADO.Stream (по крайней мере есть у меня такое подзрение). Но, есесссно, нужен какой-то ADO (какой точно — не скажу).
Ну и если уж совсем нужно — тогда прийдётся свой ActiveX писать и оборачивать IStream в IDispatch-cовместимый интерфейс
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[13]: минусы Ruby
От: FR  
Дата: 02.06.06 19:11
Оценка:
Здравствуйте, Left2, Вы писали:

C>>Вот кто бы рассказал мне как на JS работать с бинарными файлами


L>Ага, а ещё как числобробилки на нём писать

L>А ежели серьёзно — вроде бы можно через ADO.Stream (по крайней мере есть у меня такое подзрение). Но, есесссно, нужен какой-то ADO (какой точно — не скажу).
L>Ну и если уж совсем нужно — тогда прийдётся свой ActiveX писать и оборачивать IStream в IDispatch-cовместимый интерфейс

Да значит все-таки JS не серъезный язык , в том же руби или на питоне, легко работать с бинарными файлами. Кстати зря сравниваешь с числодробилками, я писал сборщик специализированного бинарного ресурсного файла, со сжатием и частичной шифрацией на чистом питоне, скорость очень приличная.
Re[8]: минусы Ruby
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.06.06 00:15
Оценка:
Здравствуйте, VladGalkin, Вы писали:

VD>>А ты его среды видел? Все через одно место.


VG>Ну это уже даже не смешно... Многим средам ещё ..ать и ..ать до сред Smalltalk, из которых, собственно, современные IDE и пошли.


Ну, да. Видишь как народ толпами ломится за счастьем? И я нет. Видимо он тупой. Самое время вспомнить что-то вроде "силлионы мух не могут ошибиться...".
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: минусы Ruby
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.06.06 00:15
Оценка:
Здравствуйте, eao197, Вы писали:

E>Руби то хоть один пользуется. А вот кто пользуется Nemerle вообще не понятно, а разговоров


Шутку понял, смешно.

VD>>Мне вот тоже влом тратить пол часа, чтобы прочесть все это ради спортивного интереса.


E>Уже есть одна. И, если бы ты прочел хотя бы пару первых абзацев, то понял бы о чем речь. Хотя ты можешь и не знать, что репозиторий svn 1.1 на базе bdb не открывается svn 1.3 и репозиторию требуется конвертация (самым простым вариантом которого является dump/load).


Поздравляю с почином! Ща мы быстренько всех поддерживающих тебя в этом споре личностей заставим туда по оценочке поставить. Жаль, что их круг заранее определен и в него не входит тех, кто действительно воспользуется тем что там описано.

E>А если бы прочитал, то наверняка бы предложил несколько более удобных способов реализации того же самого на Nemerle или C#. Еще бы, это же такие языки, которые любую задачу позволяют решать в лет


Все задачи которые мне надо было решить я решил. А решать те что мне не надо, я не буду. И на понт тут меня не взять. Хватит времени убитого на перепалку с вами.

E>На этом сайте явное доминирование .NET и C++, даже Java (по крайней мере в Средствах разработки, Исходниках и Философии) в глубоком заднем проходе. Так что RSDN не показатель востребованности Руби, Перла или Питона.


А, да, да... РСДН забивает свободу. "Скажи свободе ДА"... Можно правда предположить, что в нашей стране (как минимум) просто нет такого интереса к разным Руби (к Яве, кстати, он все же есть, наш форум по ней не так мал). Но это сразу рушит теорию заговора. А жаль...

VD>>Из с криптов массовое распространение получил ЯваСкрипт и тот потому что в броузеры вмонтирован и по факту является единственным средством их расширения.


E>Да уж, это вообще но комментс.


Да? А что тогда продолжаешь?

E>Хотя, все же спрошу: JavaScript где-нибудь как самостоятельный язык программирования используется (без браузера и не как встроенный язык)?


Это смотря что понимать под словом "используется". Если серьезные маштабы, то вряд ли. Если вообще, то конечно используется. Уверен, что и на ВБ-скрипте можно не мало примеров найти.

E>А чего ты ожидал после обзывания меня маргиналом?

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

Вот потому и обозвал. Сори, конечно, за сам факт.

E>Ничего. Просто говорю, что если для тебя привычным и логичным является ToString, то точно так же для других привычным и логичным является to_s.


Не, не. Не в коем случае не стоит смешивать эти два понятия — "привычное" и "логичное". ToString не является для меня привычным. Но он является для меня логичным. Более того обоснование того почему он так назван, а не к примеру, itoa или to_s, я считаю зравыми, а цели полезными. Потому я называю тех кто борется с этим аргументируя откровенно полхой подход привычками — маргиналами. Маргинальным для меня является само обоснование в корен не верных и пагубных привычек. Уверен, что какой-нибудь бомж тоже аргументирует то почему он вместо таго чтобы выматься и попытаться найти работу не моется и занимается поберательством.

Именно по этому я прекрасно понимаю Зверька когда он рассказывает о том, что хорошего он нашел в Руби, и не понимаю тебя, когда ты доказывашь, что плохое в Руби — это на самом деле нормально.

E>Поскольку предназначены для одного и того же и имена логически вычисляются: to (действие) + имя типа.


Прости, ты прикидывашся или для тебя s — это нормальное имя типа?

E> В Ruby имя типа обозначается короче.


Я еще бы поколебался если бы название было to_str. Тут уже действительно понятно о чем речь, в общем-то, и нужно быть немного пижоном, чтобы ассоциировать str со struts, например. Но считать нормальным однобуквенное имя типа!!! Увольте.

Так вот я понял бы, что значит str, но я так же понимаю почему это плохо. Люди стремятся к единообразию и если допустить str в публичном интерфейсе, то завтра появится def для обозначения defaulte, а после завтра появится ajd_to_jd... и пошло, поехало. В итоге вместо кода получается шифровка. Добавляем к ней случайные опечатки в именах переменных (мы и это считаем мелочами) и вот уже на горизонте мы видим результат который без пол литра не понять.

E> Вот и вся разница.


Ага.

E>Странным мне кажется то, что этому придается такое большое значение.


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

VD>>А зачем? Главное, что я понял, что деалает метод. А уж подробности исчисления дат меня не интересует. Мне достаточно того, что мне он на фиг не упал. А вот если бы он был мне нужен, то я знал бы эти подробности.


E>Так вот, я так же не знаю, что такое Astronomical Julian Day, поэтому метод ajd_to_jd мне на фиг не упал. А если бы он был мне нужен, то имя ajd_to_jd было бы для меня абсолютно понятным.


Серьезно? Тогда понятно. Конечно если не знать английский на таком уровне, то разница между "а" и "Астрономическое" действительно не очевидна.

VD>>Рад что тебе весело. Меня вообще радует когда я кого-то радую. Будь то попутчик в лифте или представитель одного из направлений нетрадиционного секса с компьютерами.


E>Сильно сказано

E>Только в сексе ведь как -- главное, чтобы по согласию, без насилия, без последствий и в удовольствие.

Ну, чтобы всем в удовольствие и без последствий, то конечно лучше с комьютером.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: минусы Ruby
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.06.06 00:15
Оценка:
Здравствуйте, Kluev, Вы писали:

Моэет js vs. bash все же где-то в другом месте разведете?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: минусы Ruby
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.06.06 00:15
Оценка:
Здравствуйте, Mamut, Вы писали:

VD>>Ага. Оно и видно. Один пользуется, а рассуждений о Руби как будто на нем все пишут.


M>Справедливости ради замечу, что интерес к Руби в интернете растет.


Справедливости ради, тоже позволю себе заметить, что это баян. Причем место ему в юморе. Мы же это воде обсуждали.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: минусы Ruby
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.06.06 13:25
Оценка:
Здравствуйте, eao197, Вы писали:

E>Это больше похоже на неприятие точек зрения, отличных от твоей.


А в чем должно выражаться приятие? Я считаю иначе и другие мнения анализирую на предмет проверки собственного. Пока я не убедился в том, что ошибаюсь я придерживаюсь своей точки зрения. Мои оппоненты зачастую придерживаются полностью абстурдных точек зрения и не грушаются этого.

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

VD>>Прости, ты прикидывашся или для тебя s — это нормальное имя типа?


E>Да, после нескольких недель программирования на Ruby это имя совершенно нормальное.


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

VD>>Я еще бы поколебался если бы название было to_str. Тут уже действительно понятно о чем речь, в общем-то, и нужно быть немного пижоном, чтобы ассоциировать str со struts, например. Но считать нормальным однобуквенное имя типа!!! Увольте.


E>Ты будешь долго смеяться, но to_str так же есть. Чаще всего это синоним для to_s, но не всегда.


Ну, что же? Спасибо за пример доказывающих твою не правоту.

VD>>Так вот я понял бы, что значит str, но я так же понимаю почему это плохо. Люди стремятся к единообразию и если допустить str в публичном интерфейсе, то завтра появится def для обозначения defaulte, а после завтра появится ajd_to_jd... и пошло, поехало. В итоге вместо кода получается шифровка. Добавляем к ней случайные опечатки в именах переменных (мы и это считаем мелочами) и вот уже на горизонте мы видим результат который без пол литра не понять.


E>Это фобия.


Отнюдь. Яеткий логический рассчет и проверка практикой.

E>Есть другое, более логичное правило -- наиболее часто используемые методы/идентификаторы с четко и давно определенной семантикой делаются наиболее короткими (to_s, to_i, to_f, eql?).


Я правильно понял, что ajd_to_jd — это как раз пример наиболее часто используемого метода?
И правильно ли я понял, что eql дает приемущество над equal и тем более над IsEqual, а to_f над to_fact, to_flat и т.п.?
Если да, то в чем заключается приемущество? Уж не в скорости печати?

E> А редко используемые или неоднозначно трактуемые -- длинными (assert_nothing_raised). Этакий код Хавмана. И, главное, на выходе получается читабельный и сопровождаемый код.


Да, да, бомжы тоже считают, что из незаслужено с улиц удаляют.

E>>>Так вот, я так же не знаю, что такое Astronomical Julian Day, поэтому метод ajd_to_jd мне на фиг не упал. А если бы он был мне нужен, то имя ajd_to_jd было бы для меня абсолютно понятным.


VD>>Серьезно? Тогда понятно. Конечно если не знать английский на таком уровне, то разница между "а" и "Астрономическое" действительно не очевидна.


E>Не понял шутки юмора.


Не расстраивайся, может со временем дойдет.

E> Метод ajd_to_jd существует не сам по себе, а в классе Date. Что сразу же сужает возможность трактования "a" в ajd_to_jd как Astronomical.


А... Ну, это другое дело! Как я сразу не догадался, что нахождение в классе Даты сужает смысл буквы "а" до "Астрономии".
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: минусы Ruby
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.06.06 13:25
Оценка:
Здравствуйте, Mamut, Вы писали:

M>Ну, на РСДН есть как минимум четыре человека, которые, как я понимаю, Руби пользуются. Ну, ладно, себя я пока не буду включать Тогда три. Это уже сила и мы имеем право на свои священные войны


От это пожалуйста. Право каждого на лево священно и неприкасаемо.

Вот только уж откровенные подлоги приводить в качестве аргумента не стоит. Руби там вообще сражается за мифическе доли процента с Коболом, так что это даже обсуждать не хочется. Но вот то, что С самый популярный язык в мире — это уже полнейший бред. Это настолько очевидная глупость, что даже осудать ее не хочется.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: минусы Ruby
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 03.06.06 19:16
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Вот только уж откровенные подлоги приводить в качестве аргумента не стоит. Руби там вообще сражается за мифическе доли процента с Коболом, так что это даже обсуждать не хочется. Но вот то, что С самый популярный язык в мире — это уже полнейший бред. Это настолько очевидная глупость, что даже осудать ее не хочется.


Ты на какую-то другую табличку смотришь? Табличка на TIOBE показывает, что самый популярный язык -- Java. И с этим трудно спорить.

И я сильно сомневаюсь, что количество информационных ресурсов, на которых упоминается C# больше, чем тех, на которых упоминается C.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[11]: минусы Ruby
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 03.06.06 20:48
Оценка:
Здравствуйте, VladD2, Вы писали:

E>>Это больше похоже на неприятие точек зрения, отличных от твоей.


VD>А в чем должно выражаться приятие? Я считаю иначе и другие мнения анализирую на предмет проверки собственного. Пока я не убедился в том, что ошибаюсь я придерживаюсь своей точки зрения. Мои оппоненты зачастую придерживаются полностью абстурдных точек зрения и не грушаются этого.


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

VD>>>Прости, ты прикидывашся или для тебя s — это нормальное имя типа?


E>>Да, после нескольких недель программирования на Ruby это имя совершенно нормальное.


VD>А, да, да... Бомж после некоторого аутотренинга тоже внушает себе, что находиться на центральной станции мето в немытом виде вполне нормально. Ведь к собственному запаху он привык, а остальные его не волнуют.


Ты думаешь, что он что-то себе внушает? Да еще аутотренингом?
Все проще -- он живет так, как ему удобно.
Ты вот пытаешься внушить всем окружающим подавляющее преимущество .NET, C# и сейчас уже Nemerle. Тебе это кажется нормальным, тебе это удобно. И, по большому счету, остальные тебя так же не волнуют, поскольку ты просто проходя мимо можешь объявить чужую точку зрения абсурдной.

E>>Ты будешь долго смеяться, но to_str так же есть. Чаще всего это синоним для to_s, но не всегда.


VD>Ну, что же? Спасибо за пример доказывающих твою не правоту.


Да уж, твою логику понять я не в силах. Поскольку своей неправоты я не увидел. Но, чтобы расставить все точки над i для читателей, которые не сильны в Ruby, я процитирую соответствующий фрагмент Programming Ruby (перевод мой, не литературный):

Standard Protocols and Coercions

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

Некоторые объекты имеют больше чем одно натуральное представление. Например, вы можете писать класс Roman для представления римских чисел (I, II, III, IV, V и так далее). Этот класс не обязательно будет наследником класса Integer, поскольку его объекты представляют числа, но не числа в их обычном смысле. В то же время они обладают качествами Integer-ов. И было бы здорово иметь возможность использовать объекты класса Roman там, где Ruby ожидает встретить целое число.

Чтобы сделать это в Ruby есть концепция conversion protocols -- объект может выбрать способ сконвертировать себя в объект другого типа. Ruby имеет три стандартных способа выполнения этого.

Мы уже рассмотрели первый. Такие методы, как to_s и to_i конвертируют своих получателей в строки и целые числа. Эти методы конвертации не являются строгими: если объект имеет какой-то способ представления себя в виде строки, то он, вероятно, будет иметь метод to_s. Наш класс Roman возможно будет реализовывать метод to_s для возвращения строкового представления числа ('VII' к примеру).

Второй метод конвертации использует методы с такими именами, как to_str и to_int. Это строгие функции конвертации: вы реализуете их только если ваш объект естественным образом может использоваться в любом месте, где может быть использована строка или целое. Для примера, объекты класса Roman имеют естественное представление в виде целого и поэтому реализуют to_int. Но, когда речь заходит о строках, то приходится задумываться чуть больше.

Римские цифры определенно имеют строковое представление, но являются ли они строками? Можем ли мы использовать их там, где мы можем использовать строки? Нет, скорее всего нет. Логически, они являются представлениями целых. Вы можете записать их в виде строки, но они не совместимы со строками. По этой причине класс Roman не будет реализовывать метод to_str -- поскольку он не является настоящей строкой. Просто запомните: римские цифры могут быть сконвертированы в строку посредством to_s, но они не являются строками, поэтому для них не реализуется метод to_str.

Чтобы посмотреть, как это работает на практике, взглянем на открытие файла. Первым параметром File.new может быть как уже существующий дескриптор (целое число) или имя открываемого файла. При этом Ruby не делает простую проверку типа первого параметра на соответствие Fixnum или String. Вместо этого File.new дает шанс объекту-параметру выразить себя либо как дескриптор, либо как строку. Если бы он был написан на Ruby, он бы выглядел как что-то подобное:

class File
  def File.new(file, *args)
    if file.respond_to?(:to_int)
      IO.new(file.to_int, *args)
    else
      name = file.to_str
      # call operating system to open file 'name'
    end
  end
end


Теперь посмотрим, что произойдет, если мы хотим передать дескриптор файла, сохраненный в объекте типа Roman, в File.new. Т.к. наш класс реализует to_int, первое обращение к respond_to? окажется успешным. Мы передадим целочисленное представление нашего числа в IO.open, и возвращеный дескриптор файла будет обернут в новый объект IO.


Так же в стандартной библиотеке Ruby определены следующие методы конвертации:
to_ary -> Array
to_hash -> Hash
to_int -> Integer
to_io -> IO
to_proc -> Proc
to_str -> Strint
to_sym -> Symbol
Ну и уже упомянутые to_s и to_i.

Так что наличие подобных методов конвертации является просто соглашением, таким же, как соглашение об именовании, которые являются стандартными в Java или .NET (хотя лично мне они кажутся неудобными, тем не менее им приходится следовать). Весь фокус в том, что названия методов конвертации в Ruby удобны при практическом использовании.

E>>Есть другое, более логичное правило -- наиболее часто используемые методы/идентификаторы с четко и давно определенной семантикой делаются наиболее короткими (to_s, to_i, to_f, eql?).


VD>Я правильно понял, что ajd_to_jd — это как раз пример наиболее часто используемого метода?


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

VD>И правильно ли я понял, что eql дает приемущество над equal и тем более над IsEqual, а to_f над to_fact, to_flat и т.п.?


Дело в том, что eql? -- это не аналог IsEqual. Это аналог opCmd из D. Если объект реализует eql? и подключает mixin Comparable, то получает в свое распоряжение операторы ==, <, > и прочие. Метод equal? в Ruby сравнивает внутренние идентификаторы объектов, т.е., как оператор == в Java, позволяет проверить, указывают ли две ссылки на один и тот же объект.
Про to_f -- см. выше.

VD>Если да, то в чем заключается приемущество? Уж не в скорости печати?


В объеме функции. Короткие имена делают функции маленькими, лаконичными и понятными даже без комментариев.

E>> А редко используемые или неоднозначно трактуемые -- длинными (assert_nothing_raised). Этакий код Хавмана. И, главное, на выходе получается читабельный и сопровождаемый код.


VD>Да, да, бомжы тоже считают, что из незаслужено с улиц удаляют.


На конференции RubyConf2005 был доклад Akira Tanaka "open-uri, Easy-to-Use and Extensible Virtual File System", в котором особое место отводится тому, как проектировать Easy-to-Use API. Вот некоторые цитаты со слайдов доклада:

How to Design Easy-to-Use API
* Save brain power
* Evolve gradually



Save brain power
Fewer Things to Learn
* Fewer constructs for pragmatic usages
* Huffman coding
* DRY
* No configuration is good configuration
* Reuse user knowledge
* Infrastructure friendly


Fewer constructs for pragmatic usages
Fewer construct decrease things to learn
* open vs Net::HTTP.get, Net::HTTP#get, etc.
* This is not minimalism.
* The target of "fewer" is not all constructs.
Pragmatic usages should be supported by small constructs.


Huffman coding
* Shorter for frequent things
* Longer for rare things
Optimize for frequent things.
Ex: p (пример с использованием метода Kernel#p, который печатает результат вызова у объекта метода inspect)


Ex: p
p obj

* Very frequent use
* Bad name in common sence
* Almost no problem because everyone knows


Ex: pp and y (примеры с методами pp (pretty printer) и y (преобразование в YAML))
* Bad name in common sence
* Problematic than p because not everyone knows.


Ex: to_s and to_str
to_s shorter. frequently used.
to_str longer. internal use.


Candidates for Huffman codes
* Method name
* Other name
* Convenience method
* Language syntax
* etc.


Encourage Good Style
* Programmer like short code
* Short code should be designed as good style


ну и так далее. Очень интересный и полезный доклад.

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

E>> Метод ajd_to_jd существует не сам по себе, а в классе Date. Что сразу же сужает возможность трактования "a" в ajd_to_jd как Astronomical.


VD>А... Ну, это другое дело! Как я сразу не догадался, что нахождение в классе Даты сужает смысл буквы "а" до "Астрономии".


Вот ты прикалываешься, а я перед использованием классов (в том числе и класса Data) читаю документацию по классу. При этом я узнаю не только про наличие метода ajd_to_jd, но и про его назначение и примеры использования. И таки да, смысл буквы "a" в ajd_to_jd сразу же сужается до Astronomical.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[12]: минусы Ruby
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.06.06 21:58
Оценка:
Здравствуйте, eao197, Вы писали:

E>Ты на какую-то другую табличку смотришь? Табличка на TIOBE показывает, что самый популярный язык -- Java. И с этим трудно спорить.


E>И я сильно сомневаюсь, что количество информационных ресурсов, на которых упоминается C# больше, чем тех, на которых упоминается C.


1. Количество упоминаний С посчитать практически невозможно, так как это просто буква алфавита. Даже C# тяжело, так как это в общем-то нота. Ява это еще по совместительству кофе, мотоциклы, остров и даже среда выполнения.
2. Измерять популярность языков можно только посчитав количество активно программирующих на них людей или количество развиваемых на них проектов.
3. С уже лет 10 как явно проигрывает по популярности С++. Это как минимум. И если кто-то говорит обратно, то его остальные выводы вызвают огромные сомнения.

Короче, в поиск... повторять одно и то же смысла не вижу.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: минусы Ruby
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.06.06 22:34
Оценка:
Здравствуйте, eao197, Вы писали:

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


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

E>Ты думаешь, что он что-то себе внушает? Да еще аутотренингом?


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

E>Все проще -- он живет так, как ему удобно.


Ага. Он это первым делом себе обясняет. Ведь удобно же не мыться, не стирать одежду... А обратное не удобно. Но есть нормы приличия, общественое мнение... У человека всегда есть что выбрать. Бомж выбирает "удобство".

E>Ты вот пытаешься внушить всем окружающим подавляющее преимущество .NET, C# и сейчас уже Nemerle. Тебе это кажется нормальным, тебе это удобно. И, по большому счету, остальные тебя так же не волнуют, поскольку ты просто проходя мимо можешь объявить чужую точку зрения абсурдной.


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

E>>>Ты будешь долго смеяться, но to_str так же есть. Чаще всего это синоним для to_s, но не всегда.


VD>>Ну, что же? Спасибо за пример доказывающих твою не правоту.


E>Да уж, твою логику понять я не в силах.


А что тут непонятного? См. выделенное жирным.

E> Поскольку своей неправоты я не увидел.


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

E>Некоторые объекты имеют больше чем одно натуральное представление. Например, вы можете писать класс Roman для представления римских чисел (I, II, III, IV, V и так далее). Этот класс не обязательно будет наследником класса Integer, поскольку его объекты представляют числа, но не числа в их обычном смысле. В то же время они обладают качествами Integer-ов. И было бы здорово иметь возможность использовать объекты класса Roman там, где Ruby ожидает встретить целое число.


Во как? Забавные рассуждения. Для меня тип цифр — это всего лишь экранное представление. А оказывается на каждый тип можно по классу завести. За такие примеры надо от церкви отлучать.

E>Чтобы сделать это в Ruby есть концепция conversion protocols -- объект может выбрать способ сконвертировать себя в объект другого типа. Ruby имеет три стандартных способа выполнения этого.


E>Мы уже рассмотрели первый. Такие методы, как to_s и to_i конвертируют своих получателей в строки и целые числа. Эти методы конвертации не являются строгими: если объект имеет какой-то способ представления себя в виде строки, то он, вероятно, будет иметь метод to_s. Наш класс Roman возможно будет реализовывать метод to_s для возвращения строкового представления числа ('VII' к примеру).


E>Второй метод конвертации использует методы с такими именами, как to_str и to_int. Это строгие функции конвертации: вы реализуете их только если ваш объект естественным образом может использоваться в любом месте, где может быть использована строка или целое. Для примера, объекты класса Roman имеют естественное представление в виде целого и поэтому реализуют to_int. Но, когда речь заходит о строках, то приходится задумываться чуть больше.


E>Римские цифры определенно имеют строковое представление, но являются ли они строками? Можем ли мы использовать их там, где мы можем использовать строки? Нет, скорее всего нет. Логически, они являются представлениями целых. Вы можете записать их в виде строки, но они не совместимы со строками. По этой причине класс Roman не будет реализовывать метод to_str -- поскольку он не является настоящей строкой. Просто запомните: римские цифры могут быть сконвертированы в строку посредством to_s, но они не являются строками, поэтому для них не реализуется метод to_str.


Нда, у вопросу допустимости сокращений это конечно отношения не имеет. Но сами по себе рассуждения наталкивают на нехорошие мысли о их авторах.

E>Так же в стандартной библиотеке Ruby определены следующие методы конвертации:

E>to_ary -> Array
E>to_hash -> Hash
E>to_int -> Integer
E>to_io -> IO

Офигительно информативно.

E>to_proc -> Proc


Преобразовать в процессор? Однако Руби силен!

E>to_str -> Strint

E>to_sym -> Symbol
E>Ну и уже упомянутые to_s и to_i.

Ну, и ответь на вопрос. Что сэкономили авторы на этих сокращениях?

E>Так что наличие подобных методов конвертации является просто соглашением,


Это я и так понял. Я не понял зачем это нужно? Зачем усложнять другим жизнь? Что экономится при потере 2-5 букв?

E> таким же, как соглашение об именовании, которые являются стандартными в Java или .NET (хотя лично мне они кажутся неудобными, тем не менее им приходится следовать).


Соглашения типа Кэмел, Паскаль и т.п. это дело вкуса и договоренности. На то они и соглашения. Но вот согращения в публичном интерфейсе — это вопрос уже не вкуса, а разуности. И в Яве и в Дотнете есть серьезные статьи обосновывающие почему нужно давать понятные называния. Мне казалось, что это следствие бюрократии царящей в больших конторах, так как то что названия должны быть понятными без догадок казалось мне очевидным, но твои слова убедимли меня, что я ошибался.

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


Я уже раз 10 спросил... чем?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: минусы Ruby
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 04.06.06 08:06
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Сори, я не объявляю все другие мнения абсурдными. Я назваю абсурдом то что считаю абсурдом. И уж так совпало, что часто их высказываешь именно ты. Вот однобуквенные идентификаторы в публичных интерфейсах один из таких примеров.


Знаешь, это напоминает "Я бью по морде просто потому, что могу ударить по морде". Тебе мое мнение кажется абсурдом и ты об этом говоришь. Хотя стоило бы задуматья, может ты считаешь это абсурдом просто по стечению обстоятельств и в силу каких-то собственных привычек.

Например, однобуквенные идентификаторы в публичных интерефейсах. Ты считаешь, что это зло. В общем смысле это так и есть. Но, если однобуквенный идентификатор полезен и информативен в конкретном контексте (и является более выгодным чем многословные альтернативы) то не использование такого идентификатора -- это догматизм.

Например, в CGI::Extension есть метод a(). И он является генератором HTML тега <a>. Вызывает ли его использование в контексте генерации HTML-страницы проблемы с его использованием?
a("HREF" => "http://www.example.com", "TARGET" => "_top") { "Example" }

Нет.
Нужно ли было его обозвать anchor()? Сильно сомневаюсь, поскольку это, во-первых, догматизм, и, во-вторых, не соответствует аналогичному понятию из HTML.

E>>Ты думаешь, что он что-то себе внушает? Да еще аутотренингом?


VD>Ага. Уверен в этом.


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

E>>>>Ты будешь долго смеяться, но to_str так же есть. Чаще всего это синоним для to_s, но не всегда.


VD>>>Ну, что же? Спасибо за пример доказывающих твою не правоту.


E>>Да уж, твою логику понять я не в силах.


VD>А что тут непонятного? См. выделенное жирным.


Да, опять ничего не понял. Если объект в Ruby может использоваться вместо строки, то он определяет метод to_str. А метод to_s делает синонимом для to_str. Таких случаев в Ruby много. Но, если объект не может быть строкой, но нуждается в строковом представлении (а это часто бывает нужно), то определяется только метод to_s. А может и требоваться наличие разных реализаций to_str и to_s. Например:
class ConnectionParams
  attr_reader :host, :login, :password :port
  ...
  # Выдает строку, которую можно использовать при обращении к open.
  # В формате "[<login>[:<password>]@]<host>[:<port>]"
  def to_str
    r = ""
    if login
      r << login
      r << ":#{password}" if password
      r << "@"
    end
    r << host
    r << ":#{port}" if @port
  end

  # Создает описание объекта без указания пароля.
  # В формате "[<login>@]<host>[:<port>]"
  # Делает возможным логирование объекта ConnectionParams в
  # небезопасные журнальные файлы.
  def to_s
    r = ""
    r << "#{login}@" if login
    r << host
    r << ":#{port}" if @port
  end
end

# Использование:
url = ConnectionParams.new( host, login, password )
logger.info( APP ) { "opening #{url}..." } # Пароль не виден.
data = read( url ) # Пароль используется.


VD>Во как? Забавные рассуждения. Для меня тип цифр — это всего лишь экранное представление. А оказывается на каждый тип можно по классу завести. За такие примеры надо от церкви отлучать.


Ага, цепляться к примеру (который приводится для того, чтобы даже неискушенные читатели могли понять о чем речь) гораздо проще, чем вникнуть в суть. Ну был бы не Roman, а IODescriptor или Sha1Hash, или даже RegExp (который имеет строковое представление, т.е., to_s, но не является строкой, т.е. нет to_str).

VD>Нда, у вопросу допустимости сокращений это конечно отношения не имеет. Но сами по себе рассуждения наталкивают на нехорошие мысли о их авторах.


Фрагмент был приведен не для того, чтобы объяснить допустимость сокращений. А для того, чтобы показать, что в Ruby есть стандартный механизм, использующие данные сокращения. Ты можешь считать его не логичным или порочным. Но, он есть и для пользователя Ruby он объективная реальность. Такая же, как объявление модулей с помощью ключевого слова module, а функций -- с помощью def. С этим ничего не поделаешь, так же как и с использованием для указания наследования в Java ключевого слова extends вместо двоеточия из C++. Изучающий Ruby просто принимает это как данность. Так же, как методы ToString или IsEqual в .NET.

E>>Так же в стандартной библиотеке Ruby определены следующие методы конвертации:

E>>to_ary -> Array
E>>to_hash -> Hash
E>>to_int -> Integer
E>>to_io -> IO

VD>Офигительно информативно.


Да уж. Если переписать как ToArray, ToHash, ToInt, ToIO информативности сразу же добавиться. Просто на порядок.

E>>to_proc -> Proc


VD>Преобразовать в процессор? Однако Руби силен!


Дурку выключи.

E>>to_str -> Strint

E>>to_sym -> Symbol
E>>Ну и уже упомянутые to_s и to_i.

VD>Ну, и ответь на вопрос. Что сэкономили авторы на этих сокращениях?


Размер программы. Для меня
while line = gets
    if m = ( /^(.+)"router::trx\.([^"]+)"(.+)$/.match( line ) )
        puts m[1] + m[2].to_i(16).to_s + m[3]
    else
        puts line
    end
end

выглядит предпочтительнее, чем:
puts m[1] + m[2].to_integer(16).to_string + m[3]

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

E>>Так что наличие подобных методов конвертации является просто соглашением,


VD>Это я и так понял. Я не понял зачем это нужно? Зачем усложнять другим жизнь? Что экономится при потере 2-5 букв?


Экономится внимание человека, читающего после тебя твою программу.

VD>Соглашения типа Кэмел, Паскаль и т.п. это дело вкуса и договоренности. На то они и соглашения. Но вот согращения в публичном интерфейсе — это вопрос уже не вкуса, а разуности. И в Яве и в Дотнете есть серьезные статьи обосновывающие почему нужно давать понятные называния. Мне казалось, что это следствие бюрократии царящей в больших конторах, так как то что названия должны быть понятными без догадок казалось мне очевидным, но твои слова убедимли меня, что я ошибался.


Скорее это следствие бюрократического догматизма. Нужно требовать, чтобы имена (не только в публичных интерфесах) были не противоречивыми и понятными, самодокументирующими по возможности. Но вот отбрасывать на этом основании возможность однобуквенных методов -- это уже перебор и перестраховка. Иногда (редко, но бывает) однобуквенные идентификаторы в определенных контекстах -- это только на пользу. В конце-концов, используют же <a> вместо <anchor>, <b> вместо <bold> и e-mail вместо electronic-mail.

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


VD>Я уже раз 10 спросил... чем?


Еще раз повторю -- компактностью получаемого кода без потери его читабельности и сопровождаемости.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re: Очередной сеанс языкометрии :)
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.06.06 14:21
Оценка:
Здравствуйте, Андрей Хропов, Вы писали:

АХ>Вот я сделал такую попытку, посмотрев на количество результатов выводимых по проектам в которых используется тот или иной язык на sourceforge.net.


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

АХ>Вот что получилось (список не полный, смотрел то что мне интересно):

АХ>

АХ>Java — 19321
АХ>C++ — 18125
АХ>C — 16664
АХ>C# — 3984
АХ>D — 35
АХ>Visual Basic — 2242
АХ>VB.NET — 583
АХ>Ruby — 560
АХ>Haskell — 55


Оставим толко ярких представителей...

АХ>Конечно, это сравнение не может претендовать на абсолютную объективность (только open source, многие проекты на D,Python,Ruby лежат на родных сайтах и т.п. ),


Иенно только ОпенСорс и не весь. Только на нашем сайте полтора десятка проектов на C#.
Но не это главное. А нужно учитывать, что С++, C# и Java как раз в основном используются в коммерческих проектах. А вот С в комерческих проектах большая редкость.

Если посмотреть на то как на SF назначаются языки, то становится понятно, что для статистики он мало пригоден. На SF нет понятия "основной язык разработки". На нем есть понятие "языки используемые в проекте". При этом в такие языки часто попадают языки которые использовались для импотра библиотек или просто так как проект и для них что-то дает (например, библиотеку). Именно такими языками являются С, С++ и Ява. Достаточно задействать какой-нить NAnt, Yacc или Бизона и мы автоматом получаем С или Яву в проекте. Точно так же в проектах появляются и разного рода скрипты. Залудили чтение логов на Руби, и вот пожалуйства плюс один проект на этом языке.

Естественно, что языки вроде ОКамла или даже Шарпа редко используются как вспомогательные.

АХ>но тем не менее интересно.


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

АХ> Кстати, положение самых популярных языков приблизительно похоже на рейтинг TCPI.


Незнаю уж кстати ли, но не похожа. По их сведениям переодически С вырывается вообще на первое место. Даже на сейчас он явно превосходит С++. А это явный обман. Далее глядим на ПХП. У них он имеет ту же популярность, что и С++ с ВБ. А на SF это не так. С++ тут второй, а ВБ вообще не видно.

Кстати о ВБ. Реальная популярность ВБ значительно ниже чем ВБ.НЕТ, но на SF — это не так. Думаю, что дело тут в том, что ВБ старый язык и с начала 90-ых было создано не мало открытых проектов. Темболее, что яык очень простой. ВБ.НЕТ же молод и в основном на нем ведут коммерческую разработку. Ну, и не надо забывать, что во многом ОпенСорс занимается закрытием дыр в технологиях.

VD>>3. С уже лет 10 как явно проигрывает по популярности С++. Это как минимум. И если кто-то говорит обратно, то его остальные выводы вызвают огромные сомнения.

АХ>Проигрывает-то он проигрывает. Но проектов живых полно еще. Все-таки самый портабельный язык.

1. Живых не очень то много. Скорее не мало дохликов не мрущих, которые просто присуствуют в сети, не более того.
2. Мы говорили о популярности, так вот я просто убежден, что С по популярности на сегодня проигает очень многим языкам. Возможно даже Руби. Ведь популярность означает скорее желание использовать язык в новыхразработках. Или вообще желание использовать язык.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: минусы Ruby
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.06.06 14:21
Оценка:
Здравствуйте, eao197, Вы писали:

E>Знаешь, это напоминает "Я бью по морде просто потому, что могу ударить по морде".


Демагогия идет лесом.

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


А я и задумался и не раз. Еще даже до того как узнал твое личное мнение по этому вопросу. Прочел ни одну статью по этому поводу. Потому и уверен в данной оценке.

E>Например, однобуквенные идентификаторы в публичных интерефейсах. Ты считаешь, что это зло. В общем смысле это так и есть. Но, если однобуквенный идентификатор полезен и информативен в конкретном контексте (и является более выгодным чем многословные альтернативы) то не использование такого идентификатора -- это догматизм.


Повторяться не буду.

E>Например, в CGI::Extension есть метод a(). И он является генератором HTML тега <a>.


То есть халтуру в одной области оправдываем халтурой в другой? За тег <a> его автору морду мало набить. А уж называть метод генерирующих этот тег так же просто дибилизм. Что мешает назвать Метод как-то вроде MakeLinkReference? Ведь еще будет и MakeLinkTarget.

E> Вызывает ли его использование в контексте генерации HTML-страницы проблемы с его использованием?


100% — ДА. И если ты заучил эту шифровку — это ничего не значит для окружающих.

E>...Нужно ли было его обозвать anchor()?


Тоже мало понятно. Вот MakeLinkAnchor куда не шло. Но у тега <a> к сожалению перегруженная семантика. Он и якорем, и ссылкой может быть. Так что метода будет как не крути два.

E> Сильно сомневаюсь, поскольку это, во-первых, догматизм,


Не. Это научный рассчет. Бло проведено не одно исследование прежде чем от древнебытных сокращений перешли к разумным именам.

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

E>...Фрагмент был приведен не для того, чтобы объяснить допустимость сокращений.


Сори, но разговор именно об этом. Так что потрудись не разводить воду, а обосновать необходимость сокращений.

E>Да уж. Если переписать как ToArray, ToHash, ToInt, ToIO информативности сразу же добавиться. Просто на порядок.


Я о ToIO или to_io. Написание тут значения не имеет. Само название бессмысленно.

E>>>to_proc -> Proc


VD>>Преобразовать в процессор? Однако Руби силен!


E>Дурку выключи.


Дурку? Я залез в Лингво... Единственный перевод — процессор. proc. еще переводится как:
1) процедура
2) протокол
3) процесс

Какой из переводов предпочесть? Протокол? Процедура? Процесс?

Так что это ты выключи дурку и ответь наконец на поставленный мной вопрос. Что дает использование невнятных сокращений?

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

VD>>Ну, и ответь на вопрос. Что сэкономили авторы на этих сокращениях?


E>Размер программы. Для меня

E>
E>while line = gets
E>    if m = ( /^(.+)"router::trx\.([^"]+)"(.+)$/.match( line ) )
E>        puts m[1] + m[2].to_i(16).to_s + m[3]
E>    else
E>        puts line
E>    end
E>end
E>

E>выглядит предпочтительнее, чем:
E>
E>puts m[1] + m[2].to_integer(16).to_string + m[3]
E>

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

Ну, наконец то! Долгожданный ответ!

И что тут предпочтительного? Вот тот же код причем на статически типизированном языке:
def HexStringToIntString(hex) { int.Parse(hex, NumberStyles.HexNumber).ToString() }

foreach (line in File.ReadAllLines(path))
  PutString(regexp match (line)
  { | @"^(?<prefix>.+)""router::trx\.(?<hexStr>[^""]+)""(<sufix>.+)$"
        => prefix + HexStrToIntStr(hexStr) + sufix
    | _ => line
  });

И это еще бещ учета того, что ToString можно вывзать неявно.
Вот как можно переписать это дело если предположить что есть метод расширения .ToString(int):
foreach (line in File.ReadAllLines(path))
  PutString(regexp match (line)
  { | @"^(?<prefix>.+)""router::trx\.(?<hexStr>[^""]+)""(<sufix>.+)$"
        => $"$prefix $(hexStr.ToInt(16)) sufix"
    | _ => line
  });

По-моему значительно понятнее. Не нужно объяснять что такое m[1], to_i и т.п. Вот только регексы конечно ужасны и портят всю картину.

Подытожим. Правильно ли я понял, что засилие бессмысленных одно-двух-буквенных идентификаторов вызвано стремлением впихунть в одну строку как можно больше фунций? То есть является следствием (или причиной) неумелой декомпозиции кода?

Или все же есть более весомая причина?

Ладно, по to_i еще можно догадаться, что делает фукнция. Да и запомнить это не очень сложно. Но как догадаться что такое tr, tr_s, sub, rjust, ljust, chomp... ?

VD>>Это я и так понял. Я не понял зачем это нужно? Зачем усложнять другим жизнь? Что экономится при потере 2-5 букв?


E>Экономится внимание человека, читающего после тебя твою программу.


Что?

Это оно экономится нафигачиванием в одну строку тонны малопонятных конструкций что ли? Сори, я или идиот, или не могу понять, чем:
m[1] + m[2].to_i(16).to_s + m[3]

лучше чем:
$"$prefix $(hexStr.ToInt(16)) sufix"

или чем
prefix + HexStrToIntStr(hexStr) + sufix

По всей видимости наше понятие о прекрасном сильно разнится.

Но вкусы это одно. А вот понятность это другое. Мне пришлось пролезь по Интернету чтобы понять, что делает to_i(16), а вот понять, что делает HexStrToIntStr() или ParseHexStr() ни для кого не составит труда. Не согласен?

VD>>Соглашения типа Кэмел, Паскаль и т.п. это дело вкуса и договоренности. На то они и соглашения. Но вот согращения в публичном интерфейсе — это вопрос уже не вкуса, а разуности. И в Яве и в Дотнете есть серьезные статьи обосновывающие почему нужно давать понятные называния. Мне казалось, что это следствие бюрократии царящей в больших конторах, так как то что названия должны быть понятными без догадок казалось мне очевидным, но твои слова убедимли меня, что я ошибался.


E>Скорее это следствие бюрократического догматизма.


Ну, вот когда я увижу разумные обоснования для сокращений, я еще подумаю. А пока что я вижу банальную леть писать полноценные названия. Потому как с точки зрения чтения нет разницы читать to_s или to_string.

E> Нужно требовать, чтобы имена (не только в публичных интерфесах) были не противоречивыми и понятными, самодокументирующими по возможности.


Сам себе противоречишь. to_a, а темболее tr не являются ни не противоречивыми и ни понятными, ни самодокументирующими. То что ты их заучил ничего ровным счетом не значит. Я их учить не хочу.

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

E>Еще раз повторю -- компактностью получаемого кода без потери его читабельности и сопровождаемости.


Не, не, это нагромождение не является читабельным. Это жутик. И ты еще намеренно берешь довольно понятные названия. А если поглядеть на рельную программу, то скорость чтения исходника падает до нуля так как приходится то и дело лазить в дукументацию. Ведь даже банальной поддержки IDE нет. Получается, что пока ты не привратишь свой мозг в огромный хэш-мап засунув в него ассациации для большей части библиотечных функций и классов, ты не сможешь работать на этом языке продуктивно. А наФига тогда все выпендрежи языка?

Еще раз повторю для тех кто застрял в среднивековье. Сегодня быстро программировать можно только при поддержке IDE. Это относится и к чтению кода, и к его набиванию, и к его проектированию. При поддержке IDE длинна идентификатора (до разумных пределов конечно) уже не является важным фактором. На против она заставляет распологать на одной строке ровно столько кода, сколько можно быстро охватить взглядом. Так как в соврепменной программе всегд моного кода записать всю программу в один экран практически никогда не удается. При этом приходится анализировать классы, методы, свойства. При этмо на первый план выходят понятность идентификаторов, средства навигации по коду и другие средства автоматизации. Выразительность языка тоже играет не малую роль. Декларативные конструкции всегда проще понять, чем их императивный аналог. Тут не поспоришь. Но добиваться краткости путем потери информации — это все равно что не мыться чтобы сэкономить время.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: минусы Ruby
От: IT Россия linq2db.com
Дата: 04.06.06 16:49
Оценка:
Здравствуйте, FR, Вы писали:

VD>>По-моему значительно понятнее. Не нужно объяснять что такое m[1], to_i и т.п. Вот только регексы конечно ужасны и портят всю картину.


FR>но его код (не смотря на птичий для меня синтаксис руби) понятнее чем твой.


А мне нет.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[16]: минусы Ruby
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.06.06 20:50
Оценка:
Здравствуйте, eao197, Вы писали:

Сори, плюс ФР-у я так понимаю, можно рассаматривать как изменение позиции?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: минусы Ruby
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.06.06 20:50
Оценка:
Здравствуйте, eao197, Вы писали:

E>Если чесно, мне по барабану, является ли <a> в HTML халтурой или нет. Но, когда мне приходится генерировать HTML из программы, мне удобно пользоваться в программе такими же понятиями, как и в HTML. Это можно назвать приближением к предметной области.


Ну, если из контекста ясно, что речь идет о теге. Например:
EmitTeg.a(...)

то я не против. Но в случае Руби речь то не о том. Тут именно что сокращения ради урощения вбивания текста.

E>Окружающих Ruby программистов или просто окружающих? Если просто окружающих, то они идут лесом.


Я правильно понимаю, что Руби-программисты это отдельная каста? Мне не нравятся касты. Особенно если для вхождения в оную нужно забить голову заучиванием невнятных идетификаторов.

E>Еще раз. Названия должны быть...


Ну, я позволю себе не повторяться еще раз... с вашего позволения.

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


А чтобы знать что означает что нужно в голове создать хэш-табчичку и запоминать i -> integer, s-> string, tr -> ???... Сори у меня уже хэш испортился.

E>Название имеет смысл для Ruby программистов, т.к. IO -- это один из базовых классов в Ruby для организации ввода вывода. Поэтому to_io (или ToIO) означает, что объект может сконвертироваться в реализацию класса IO. В C++ это было бы аналогом возвращения объекта std::iostream.


Вот iostream, хотя лучше io_stream или IO.Stream, ну, да не важно, так вот iostream смысл имеет, а to_io — это снова в хэш-табличку.

E>В документацию по Ruby библиотеки нежно было залезть. Proc -- это название класса, который используется для работы с блоками кода. Соответственно, to_proc возвращает блок кода, каким-то образом связанный с объектом. Мы же здесь о Ruby все-таки разговариваем, следовательно нужно как-то ориентироваться в понятиях языка и его библиотеки.


Ясно. Снова в хэш-табличку...

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


Многие внятные, а остальные многие... правильно в хэш-табличку.

VD>>>>Ну, и ответь на вопрос. Что сэкономили авторы на этих сокращениях?


VD>>И что тут предпочтительного? Вот тот же код причем на статически типизированном языке:

VD>>
VD>>def HexStringToIntString(hex) { int.Parse(hex, NumberStyles.HexNumber).ToString() }

VD>>foreach (line in File.ReadAllLines(path))
VD>>  PutString(regexp match (line)
VD>>  { | @"^(?<prefix>.+)""router::trx\.(?<hexStr>[^""]+)""(<sufix>.+)$"
VD>>        => prefix + HexStrToIntStr(hexStr) + sufix
VD>>    | _ => line
VD>>  });
VD>>

VD>>И это еще бещ учета того, что ToString можно вывзать неявно.

E>Имхо, этот код менее понятен, чем мой.


Чем же?

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


Серьезное знание. А для того чтобы понять, что "m" у тебя некий массив mach-ей знания не требуются?
Что же касается угловых скобок, то здесь еще пример хреновый. Самый кай начинается когда вхождения целочисленные.

E> Если же использовать неявные фокусы Ruby, то можно еще интереснее:

E>
E>while gets
E>    if ~ /^(.+)"sms_router::rosbank\.([^"]+)"(.+)$/
E>        puts "#{$1}#{$2.to_i(16)}#{$3}"
E>    else
E>        puts $_
E>    end
E>end
E>

E>

Где-то я это видел... То ли в 17 мгновениях весны, то ли в Перле.

VD>>Подытожим. Правильно ли я понял, что засилие бессмысленных одно-двух-буквенных идентификаторов вызвано стремлением впихунть в одну строку как можно больше фунций? То есть является следствием (или причиной) неумелой декомпозиции кода?


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


А по-моему одно вызвано другим.

VD>>Ладно, по to_i еще можно догадаться, что делает фукнция. Да и запомнить это не очень сложно. Но как догадаться что такое tr, tr_s, sub, rjust, ljust, chomp... ?


E>А ты придумай для tr и tr_s внятные имена


Не надо вопросом на вопрос. А то ведь тяжело придумть не зная что придумывать.

E>sub, rjust, ljust -- понятны без проблем.


Серьезно? А я вот думал, что sub — это пропрограмма. Ну, привык я в Васике к этому. А что значит остальное хоть убей не понимаю.

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


... или глаза слишком узкие лыли...

E> Но remove_trailing_separators вместо chomp, имхо, это так же не есть хорошо.


Но можно что-то вроде ЧомпЧтоТоТам...

VD>>Это оно экономится нафигачиванием в одну строку тонны малопонятных конструкций что ли? Сори, я или идиот, или не могу понять, чем:

VD>>
VD>>m[1] + m[2].to_i(16).to_s + m[3]
VD>>

VD>>лучше чем:
VD>>
VD>>$"$prefix $(hexStr.ToInt(16)) sufix"
VD>>

VD>>или чем
VD>>
VD>>prefix + HexStrToIntStr(hexStr) + sufix
VD>>


E>По моему, они эквивалентны.


Серьезно?

E> Только в случае с HexStrToIntStr тебе пришлось делать функцию, которая выполняет то же самое, что и комбинация to_i(16).to_s.


Ничего страшного. Я это переживу. Сделать это нужно ровно однажды. Зато потом мне не прийдется распозновать в твоих кракозябрах что собственно происходит. Я просто прочту имя функции, пойму что она делает и пойму суть выражения. Смотреть ее мне не прийдется. Это, кстати, на любом языке решение верное.

E> При том, что название HexStrToIntStr имеет такую же смысловую нагрузку, что и to_i(16).to_s.


Правда? А я провел двадцать минут в интернете чтобы понять что же делает to_i(16). Да и не просто из алгоритма вычленить суть. Все же английский понятнее. Не находишь?

E>Это уж точно. Например, как мне помнится, абстрактная живопись тебе не нравится.


Да, и рафити тоже. Я как то классику предпочитаю. Восхищение Малевичами это не для меня.

E>Нет, не согласен. Ruby программист не будет лазить по интернету, чтобы понять, что такое to_i(16). Так же как и дотнетчик не будет искасть в MSDN описание int.Parse(hex, NumberStyles.HexNumber).


Правильно, Руби-прграммист не будет. Но потенциальный Руби программист прост не станет кенетическим.

VD>>Сам себе противоречишь. to_a, а темболее tr не являются ни не противоречивыми и ни понятными, ни самодокументирующими. То что ты их заучил ничего ровным счетом не значит. Я их учить не хочу.


E>Вот и ответ на все вопросы. Не программируешь на языке, но считаешь, что его недостатком являются слишком короткие имена методов. И учить их не хочешь потому что не программируешь на языке. Что же, логично. Только к недостаткам Ruby это не имеет никакого этношения.


Снова обсуждаем меня? Я программировал на раных языках и в разных культурах. Более того в начале соглашения дотнета/Явы воспринял с трудом, но прочтя пару статей обосновывающих то о чем я тебе говорю я понял, что доводы разумны. Последующий опыт показал сто процентную правильность теории.

VD>>Ну, а то что коротких имен можно в строку больше запихать,


E>Об этом, насколько я помню, не было и речи. Цель не в том, чтобы в одной строке было больше идентификаторов.


Зачем? Не станет же код проще от этого?

E> А в том, чтобы было меньше строк.


Где? В фунции или во всей программе?

E> А в строке -- меньше идентификаторов.


Это как-то входит в противоречие с идеей запихать в одну строку больше функций. Не находишь?

E> А идентификаторы короче, при сохранении той же читабельности. Короче принцип code less в чистом виде.


А зачем короче если "А в строке -- меньше идентификаторов". Очередная неувязочка.

VD>>Но добиваться краткости путем потери информации — это все равно что не мыться чтобы сэкономить время.


E>Видишь ли, код Хаффмана ценен тем, что он не теряет информации. Совсем. Он только позволяет записать ее компактнее.


А я вижу что теряет. На чтение твоего кода у меня уходит больше времени.

Понимашь, я только "за" краткий и читабельный код. Вот только чрезмено сокращенные идентификаторы и "коды" не делают код, ни проще, ни чище.

Я согласен с функциональщиками, что декларативне конструкции вроде паттерн-матчинга сопособны упростить чтение код, и что функционаьная декомпозиция тоже приводит к этому (как в прочем и ОО-декомпозиция).
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Очередной сеанс языкометрии :)
От: Андрей Хропов Россия  
Дата: 04.06.06 23:50
Оценка:
Здравствуйте, VladD2, Вы писали:

АХ>>Вот я сделал такую попытку, посмотрев на количество результатов выводимых по проектам в которых используется тот или иной язык на sourceforge.net.


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

Вот здесь и Filter по языку.

VD>А нужно учитывать, что С++, C# и Java как раз в основном используются в коммерческих проектах. А вот С в комерческих проектах большая редкость.

Согласен, но см. ниже.

АХ>> Кстати, положение самых популярных языков приблизительно похоже на рейтинг TCPI.


VD>Незнаю уж кстати ли, но не похожа. По их сведениям переодически С вырывается вообще на первое место.

Он там был, но сейчас Java явно и уже довольно давно впереди.

VD> Даже на сейчас он явно превосходит С++. А это явный обман. Далее глядим на ПХП. У них он имеет ту же популярность, что и С++ с ВБ. А на SF это не так.

Ну как это не так, на 4 месте:
PHP — 13917.

VD> С++ тут второй, а ВБ вообще не видно.

Ну не совсем не видно (всего лишь в 2 раза меньше C#).
Ну не знаю, я не очень люблю VB. Это чисто по-быстрому формочки наклепать, больше ничего.

VD>Кстати о ВБ. Реальная популярность ВБ значительно ниже чем ВБ.НЕТ

так скоко на VB было написано во время .com бума пока .NET не появился! Тогда это был основной язык RAD разработки. Весь Бангалор на нем вырос .
А вот на мой взгляд VB.NET нужен только для безболезненной миграции на .NET бывших VBшников, а будущего у него особо нет.
Лучше уж C# использовать (ну или в будущем Nemerle ), под который .NET и проектировали.

В MS даже петиции помнится подавали : Оставьте нам старый добрый простой VB и не надо .NET прибамбасов.

VD>Ну, и не надо забывать, что во многом ОпенСорс занимается закрытием дыр в технологиях.

Не понял.

VD>>>3. С уже лет 10 как явно проигрывает по популярности С++. Это как минимум. И если кто-то говорит обратно, то его остальные выводы вызвают огромные сомнения.

АХ>>Проигрывает-то он проигрывает. Но проектов живых полно еще. Все-таки самый портабельный язык.

VD>1. Живых не очень то много. Скорее не мало дохликов не мрущих, которые просто присуствуют в сети, не более того.

Да вот не так давно Mono на нем начали писать с 0.
Вот библиотеки Intel IPP тоже недавно написаны — тоже на C + asm.
И большинство аудио/видеокодеков, тоже насколько я знаю на C + asm вставки.

VD>Ведь популярность означает скорее желание использовать язык в новыхразработках. Или вообще желание использовать язык.

Вот-вот. Поэтому мне кажется sf.net в этом смысле интересен, поскольку большинство проектов пишут люди на том, на чем они сами хотят, а не на том на чем сказал работодатель, которому в свою очередь промывают мозги маркетологи от крупных вендоров.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[3]: Очередной сеанс языкометрии :)
От: VladD2 Российская Империя www.nemerle.org
Дата: 05.06.06 02:44
Оценка:
Здравствуйте, Андрей Хропов, Вы писали:

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

АХ>Вот здесь и Filter по языку.

Хоть убей не вижу никакого фильтра по языку. Да и надо список/рейтинг языков.

Кстати, проекты на Немерле точно есть. Сам видел пару.

АХ>Он там был, но сейчас Java явно и уже довольно давно впереди.


Все равно опережение С-ями С++-са это явный подлог.

VD>> Даже на сейчас он явно превосходит С++. А это явный обман. Далее глядим на ПХП. У них он имеет ту же популярность, что и С++ с ВБ. А на SF это не так.

АХ>Ну как это не так, на 4 месте:
АХ>PHP — 13917.

Мля, так ни так. Сравни 13 и 18! А у них по 10% на каждого.

VD>> С++ тут второй, а ВБ вообще не видно.

АХ>Ну не совсем не видно (всего лишь в 2 раза меньше C#).

Но не 10% кау у С++?

АХ>Ну не знаю, я не очень люблю VB. Это чисто по-быстрому формочки наклепать, больше ничего.


Открой на досуге ВБ.НЭТ, Шарп, Яву в ИДЕА и сравни.

VD>>Кстати о ВБ. Реальная популярность ВБ значительно ниже чем ВБ.НЕТ

АХ>так скоко на VB было написано во время .com бума

Сколько?

VD>>Ну, и не надо забывать, что во многом ОпенСорс занимается закрытием дыр в технологиях.

АХ> Не понял.

Что там понимать? Погляди на количество левых ИДЕ для Явы, Руби, Питона... А зачем они для C#? Есть всего один проект, но зато какой!

VD>>1. Живых не очень то много. Скорее не мало дохликов не мрущих, которые просто присуствуют в сети, не более того.

АХ>Да вот не так давно Mono на нем начали писать с 0.

Не правда. В Моно на С написана только малая часть кода. Джит и часть ЖЦ. Остальное на Шарпе. Более того первая версия была вообще интерпретатором и жила только под Виндой по началу. А писалась на Шарпе (МС-ном).

АХ>Вот библиотеки Intel IPP тоже недавно написаны — тоже на C + asm.

АХ>И большинство аудио/видеокодеков, тоже насколько я знаю на C + asm вставки.

И сколько таких варинтов? Они и на Фортране писались. Давай сделаем вывод, что Фортран лидер в желтой майке.

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

VD>>Ведь популярность означает скорее желание использовать язык в новыхразработках. Или вообще желание использовать язык.

АХ>Вот-вот. Поэтому мне кажется sf.net в этом смысле интересен, поскольку большинство проектов пишут люди на том, на чем они сами хотят, а не на том на чем сказал работодатель, которому в свою очередь промывают мозги маркетологи от крупных вендоров.

Ну, да, блин, Моно напримар мечтали на С написать... да так что сделали 90% на Шарпе. С в ОпенСорс выбирают зачастую по нужде. И используют по паре файлов на проект. А полядишь статистику, так почти все на С.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[18]: минусы Ruby
От: Mamut Швеция http://dmitriid.com
Дата: 05.06.06 06:47
Оценка:
E>Я к тому, что ты лихо разбрасываешься ярлыками, а если взяться за задачу серьезнее, то окажется, что не так уж и просто ее решить лучше. Вот описания методов tr и tr_s:
E>

E>str.tr(from_str, to_str) => new_str

E>str.tr_s(from_str, to_str) => new_str

E>Методы уж очень специфические и я не припоминаю случаев, когда бы я их вообще видел в Ruby коде. Так что их невнятное название очень в тему -- сначала нужно очень сильно захотеть его применить.

cf. PHP str_replace

E>Кстати, в Qt есть глобальная функция tr(), она используется для локализации сообщений приложения. С точки зрения хорошего стиля ее имя ужасно и недопустимо. Но на практике она очень удобно. Что говорит о том, что теория должна подтверждаться практикой. И если это не так, то теория не верная.


Потому что она означает translate. А вот что обозначает tr в Руби —

E>>> Но remove_trailing_separators вместо chomp, имхо, это так же не есть хорошо.


VD>>Но можно что-то вроде ЧомпЧтоТоТам...


E>Имхо, лучше уж chomp.


Qt QString::stripWhiteSpace

В общем, документацию читать все равно придется...
... << RSDN@Home 1.2.0 alpha rev. 647>>


dmitriid.comGitHubLinkedIn
Re[19]: минусы Ruby
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 05.06.06 07:34
Оценка:
Здравствуйте, Mamut, Вы писали:

E>>Я к тому, что ты лихо разбрасываешься ярлыками, а если взяться за задачу серьезнее, то окажется, что не так уж и просто ее решить лучше. Вот описания методов tr и tr_s:

E>>

E>>str.tr(from_str, to_str) => new_str

E>>str.tr_s(from_str, to_str) => new_str

E>>Методы уж очень специфические и я не припоминаю случаев, когда бы я их вообще видел в Ruby коде. Так что их невнятное название очень в тему -- сначала нужно очень сильно захотеть его применить.

M>cf. PHP str_replace


Имхо, ты не полностью прочитал описания методов tr, tr_s. Они не заменяют подстроки (как это делается в str_replace). Только отдельные вхождения символов. PHP-шная же str_replace умеет делать как то, так и другое. Поэтому если уж и брать другое название, то что-то вроде replace_char_occurencies_by и replace_char_occurencies_by_and_remove_duplicates.

В документации к tr() приведен пример, который вводит в заблуждение:
"hello".tr('el', 'ip')      #=> "hippo"

здесь просто совпадение, что 'el' в 'hello' следовали подряд. Вот, к примеру:
'hehlo'.tr('el','ip')       #=> "hihpo"


M>Потому что она означает translate. А вот что обозначает tr в Руби —

Подозреваю, что то же самое

К тому же я запамятовал, в Qt метод tr был методом класса QObject. Причем, public-методом.

E>>Имхо, лучше уж chomp.


M>Qt QString::stripWhiteSpace


Не подойдет. stripWhiteSpace удаляет все лидирующие и конечные пробелы из строки. chomp же убирает только завершающий перевод строки в конце строки (причем только последний):
irb(main):004:0> a="  hello, world!  \n"
=> "  hello, world!  \n"
irb(main):005:0> a.chomp
=> "  hello, world!  "
irb(main):006:0> a="  hello, world!  \n\n"
=> "  hello, world!  \n\n"
irb(main):007:0> a.chomp
=> "  hello, world!  \n"
irb(main):008:0>

И применяется chomp при построковом чтении текстовых файлов для изъятия перевода строки, чтобы не мешался при дальнейшей обработке:
IO.foreach( 'somefile' ) { |l| process_line( l.chomp! ) }


Так что альтернативой chomp могло бы быть название remove_last_linefeed.

M>В общем, документацию читать все равно придется...


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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[13]: минусы Ruby
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 05.06.06 07:38
Оценка:
Здравствуйте, Mamut, Вы писали:

E>>

E>>Ex: pp and y (примеры с методами pp (pretty printer) и y (преобразование в YAML))
E>>* Bad name in common sence
E>>* Problematic than p because not everyone knows.



M>Тут я позволю себе не согласиться с фразой "Almost no problem because everyone knows".


По отношению к Kernel#p -- эта фраза верна.
А вот методы pp и y действительно неудачны, о чем Танака в своей презентации и сказал.

M>Если у того же p есть alias в стиле print_method_result, то тогда нормально, а так —


У него есть более короткий alias:
puts obj.inspect



SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[14]: минусы Ruby
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 05.06.06 07:39
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Кстати, поймал себя на мысли, что чаще открываю Рефлектор, чем МСДН.


Таж фигня. Увы, качество документации никакое, сырцов нету. Вот и приходится с рефлектором карячиться. Вот с jdk сразу сырцы идут — рефлектор не нужен.
http://www.smalltalk.ru | << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[17]: минусы Ruby
От: FR  
Дата: 05.06.06 07:48
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Хм,

VD>
VD>prefix + HexStrToIntStr(hexStr) + sufix
VD>

VD>мене понятен чем
VD>
VD>m[1] + m[2].to_i(16).to_s + m[3]
VD>


VD>Во истину о вкусах не спорят.


Если так то нет
Но если взять первоначальные два куска кода то наооборот
Re[15]: минусы Ruby
От: VladD2 Российская Империя www.nemerle.org
Дата: 05.06.06 15:14
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Таж фигня. Увы, качество документации никакое, сырцов нету. Вот и приходится с рефлектором карячиться. Вот с jdk сразу сырцы идут — рефлектор не нужен.


Качество документации лично меня устравиват. Но в Рефлекторе откровенно можно узнать то, что ни в какой документации не опишут. Плюс навигация по ссылкам. А то что есть в документации мне не интересно именно потому, что я из хинтов в редакторе почти все узнаю.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[18]: минусы Ruby
От: VladD2 Российская Империя www.nemerle.org
Дата: 05.06.06 15:14
Оценка:
Здравствуйте, FR, Вы писали:

FR>Если так то нет

FR>Но если взять первоначальные два куска кода то наооборот

Ну, извини, мы обсуждали именно его. А остальное уж обвязка для работы с регексами. Напиши тоже саоме на С++ и получишь еще ту задницу.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[18]: минусы Ruby
От: VladD2 Российская Империя www.nemerle.org
Дата: 05.06.06 15:14
Оценка:
Здравствуйте, eao197, Вы писали:

VD>>Сори, плюс ФР-у я так понимаю, можно рассаматривать как изменение позиции?


E>С чего ты взял? Ведь FR сказал, что мой код ему понятнее, чем твой. С этим то я и согласился.


Re[17]: минусы Ruby
Автор: FR
Дата: 05.06.06


К тому же ты прочти его сообщение то внимательно. С чего оно начинается?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[20]: минусы Ruby
От: VladD2 Российская Империя www.nemerle.org
Дата: 05.06.06 15:14
Оценка:
Здравствуйте, raskin, Вы писали:

R>Это старая традиция из shell, на самом деле.. Эта команда появилась в

R>UNIX до написания первого POSIX (замечу, что тогда с completion было
R>туго), да так осталасть по традиции. Люди, которые захотят её
R>использовать в Рубине, скорее всего, пользовались ею и раньше. И,
R>кстати, заголовок man tr: tr — translate or delete characters .
R>Насколько здесь хорошо translate — другой вопрос.

Здорово. А как быть людям не использовавшим ее до этого (а похоже таких большинство на этом сайте)?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: минусы Ruby
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 05.06.06 15:29
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Качество документации лично меня устравиват. Но в Рефлекторе откровенно можно узнать то, что ни в какой документации не опишут. Плюс навигация по ссылкам. А то что есть в документации мне не интересно именно потому, что я из хинтов в редакторе почти все узнаю.


Я именно это и имел в виду: описано то, что понятно из названия метода и ничего больше.
http://www.smalltalk.ru | << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[14]: минусы Ruby
От: Left2 Украина  
Дата: 05.06.06 15:36
Оценка:
FR>Да значит все-таки JS не серъезный язык ,
FR>в том же руби или на питоне, легко работать с бинарными файлами.
Язык ИМХО и не должен содержать таких вещей как работа с бинарными файлами. Ну а то что таких вещей нет в стандартной библиотеке JS — специфика языка, тут конечно ничего не скажешь.

FR>Кстати зря сравниваешь с числодробилками, я писал сборщик специализированного бинарного ресурсного файла, со сжатием и частичной шифрацией на чистом питоне, скорость очень приличная.

Ты на скрипте реализовывал алгоритмы шифрования и имел приличную скорость? Это безусловно круто, я бы не стал даже пытаться решать такую задачу на скриптовом языке, разве уж только совсем по безнадёге. Хотя, возможно, у тебя алгоритмы шифрования были какими-то специфичными?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[19]: минусы Ruby
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 05.06.06 16:05
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Re[17]: минусы Ruby
Автор: FR
Дата: 05.06.06


VD>К тому же ты прочти его сообщение то внимательно. С чего оно начинается?


Вообще-то я ставил плюс на сообщение http://rsdn.ru/Forum/Message.aspx?mid=1937475&amp;only=1
Автор: FR
Дата: 04.06.06

Если бы можно было ставить оценки на части сообщения, я бы поставил плюс на фразу:

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

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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[15]: минусы Ruby
От: FR  
Дата: 05.06.06 17:02
Оценка:
Здравствуйте, Left2, Вы писали:

FR>>Да значит все-таки JS не серъезный язык ,

FR>>в том же руби или на питоне, легко работать с бинарными файлами.
L>Язык ИМХО и не должен содержать таких вещей как работа с бинарными файлами. Ну а то что таких вещей нет в стандартной библиотеке JS — специфика языка, тут конечно ничего не скажешь.

Так большинство и не содержит. Я язык и стандартную библиотеку тут не разделял.

FR>>Кстати зря сравниваешь с числодробилками, я писал сборщик специализированного бинарного ресурсного файла, со сжатием и частичной шифрацией на чистом питоне, скорость очень приличная.

L>Ты на скрипте реализовывал алгоритмы шифрования и имел приличную скорость? Это безусловно круто, я бы не стал даже пытаться решать такую задачу на скриптовом языке, разве уж только совсем по безнадёге. Хотя, возможно, у тебя алгоритмы шифрования были какими-то специфичными?

Нет алгоритм был вполне стандартный реализованный в стандартной библиотеке, и к тому шифрованных кусков было не больше 10%. Скрипт был для этой задачи очень удобен так как формат несколько раз менялся в процессе разработки.
Re: минусы Ruby
От: Курилка Россия http://kirya.narod.ru/
Дата: 05.06.06 20:21
Оценка:
Здравствуйте, Курилка, Вы писали:

...

А вот взгляд из другого лагеря — руби (с рельсами) с т.зр. пхп-программиста. Основные моменты, обращающие на себя внимание — скудность документации и некоторая "багнутость" рельс (хотя можно это оправдать молодостью фреймворка)
Re[16]: минусы Ruby
От: Left2 Украина  
Дата: 06.06.06 07:55
Оценка:
FR>Нет алгоритм был вполне стандартный реализованный в стандартной библиотеке
Значит, реализован не на скрипте?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[17]: минусы Ruby
От: FR  
Дата: 06.06.06 10:07
Оценка:
Здравствуйте, Left2, Вы писали:

FR>>Нет алгоритм был вполне стандартный реализованный в стандартной библиотеке

L>Значит, реализован не на скрипте?

Какое это имеет значение если моя задача решается на этом самом скрипте?
Re[18]: минусы Ruby
От: Left2 Украина  
Дата: 06.06.06 10:21
Оценка:
FR>Какое это имеет значение если моя задача решается на этом самом скрипте?

Ты просто первый сказал о числодробилках Так вот получилось в итоге что это была совсем не числодробилка — сам алгоритм шифрования был реализован не на скрипте. Всё же кесарю-кесарево, не скриптовое это дело байтики обрабатывать с высокой скоростью
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re: минусы Ruby
От: barcik  
Дата: 06.06.06 15:37
Оценка:
Здравствуйте.
А MonoRail кто-нибудь использовал?
Re[21]: минусы Ruby
От: VladD2 Российская Империя www.nemerle.org
Дата: 07.06.06 21:05
Оценка:
Здравствуйте, Kluev, Вы писали:

K>Клоунада это когда вместо


Не, клоун это проффессия.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: минусы Ruby
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.06.06 18:20
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

VD>>Качество документации лично меня устравиват. Но в Рефлекторе откровенно можно узнать то, что ни в какой документации не опишут. Плюс навигация по ссылкам. А то что есть в документации мне не интересно именно потому, что я из хинтов в редакторе почти все узнаю.


ANS>Я именно это и имел в виду: описано то, что понятно из названия метода и ничего больше.


Вот только я это в виду не имел. Я имел в виду, что среда показывает почти весь этот хэлп. И лажить в МСДН смысла нет. И я не имел в виду, что имени метоща всегда достаточно. Просто то что можно изнать из кода ни одна документация не опшет. Если такое же средство было во времена КОМ-ма...
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: минусы Ruby
От: trophim Россия  
Дата: 10.06.06 13:48
Оценка:
Здравствуйте, Valodzka, Вы писали:

V>Если это замечает только один человек, то скорее всего с его юмором что-то не то...


Абсолютно верно. 5 баллов!
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Let it be! — Давайте есть пчелу!
Re[8]: минусы Ruby
От: Aquila http://www.wasm.ru
Дата: 20.07.06 17:40
Оценка:
Здравствуйте, eao197, Вы писали:

VD>>Ну, можешь поглядеть каков интерес к вашим Руби и Питонам на этом сайте.


E>На этом сайте явное доминирование .NET и C++, даже Java (по крайней мере в Средствах разработки, Исходниках и Философии) в глубоком заднем проходе. Так что RSDN не показатель востребованности Руби, Перла или Питона.


Ещё три года назад здесь было кем-то метко подмечено (кажется, мной ), что RSDN — это проNET'овский сайт. Это и не плохо и не хорошо, это просто так есть, было и будет .
Re[2]: минусы Ruby
От: Mamut Швеция http://dmitriid.com
Дата: 27.07.06 16:26
Оценка:
E>Вот веселый и хороший разбор ситуации вокруг Ruby вообще и RubyOnRails в частности

E>

E>Who are those who are benefiting from Ruby on Rails? Answer: O'Reilly Publishing, the authors Bruce Tate and Dave Thomas and a handful of consultants.




В целом, у него такие же проблемы, как и у Joel'a Не смог настроить и разобраться Хотя в чем-то он и прав.

Замечу, что речь идет не о Руби вообще, а о Rails в частности. Кстати, в Ruby Community периодически всплывает мысль — а как бы Rails не стал убийцей Руби в том смысле, что как бы Руби не стало "просто я зыком, на котором написан Rails".

В Rails есть две полезные вещи — это "технология с человеческим лицом" и Convention over Configuration, что позволяет меньше времени уделять борьбе с мелочами, а сконцентрироваться на, собственно, "Biznizz Lojig" (с) Lazy Cjow Rhrr

Готов ли Ruby к Enterprise? Вполне возможно — в качестве клея между приложениями, например. Почему бы нет?

Готов ли Rails к Enterprise? Скорее всего, нет. Именно и-за прооблем, описанных в посте — хранимые процедуры, скорость, проблема грамотной конфигурации веб-сервера (см. Time For A Grown-Up Server: Rails, Mongrel, Apache, Capistrano and You). Хотя, с другой стороны, несколько серьезных проектов используют Rails(особенно стоит выделить A List apart, BaseCamp, eins.de (об их мучениях — здесь)). Но это — другая история, для форума Веб программирование.
... << RSDN@Home 1.2.0 alpha rev. 647>> ... <<Ennio Morricone — Speakeasy>> ...


dmitriid.comGitHubLinkedIn
Re[5]: минусы Ruby
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 27.07.06 19:59
Оценка:
Здравствуйте, WolfHound, Вы писали:

E>>Вот еще один интересный сайт: Ohloh

WH>Название сайта весьма символично...



Желающим посмеятся над названием можно присоедениться к обсуждению на linux.org.ru


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[6]: минусы Ruby
От: Mamut Швеция http://dmitriid.com
Дата: 28.07.06 06:33
Оценка:
E>>>Вот еще один интересный сайт: Ohloh
WH>>Название сайта весьма символично...

E>


E>Желающим посмеятся над названием можно присоедениться к обсуждению на linux.org.ru



Хм... Ohloh здесь:

Scott Collison — Co-Founder и CEO. Работал в Microsoft. Jason Allen — Co-Founder. Работал в Microsoft.

Финансовая поддержка:

Pradeep Singh — бывший Микрософтовский top-manager. Paul Maritz — член исполнительного комитета и управляющий всей компанией Микрософт с 1986 по 2000 год.

... << RSDN@Home 1.2.0 alpha rev. 647>> ... <<Ennio Morricone — Speakeasy>> ...


dmitriid.comGitHubLinkedIn
Re[7]: минусы Ruby
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 28.07.06 06:50
Оценка:
Здравствуйте, Mamut, Вы писали:

M>Хм... Ohloh здесь:

M>

Scott Collison — Co-Founder и CEO. Работал в Microsoft. Jason Allen — Co-Founder. Работал в Microsoft.

M>Финансовая поддержка:

M>Pradeep Singh — бывший Микрософтовский top-manager. Paul Maritz — член исполнительного комитета и управляющий всей компанией Микрософт с 1986 по 2000 год.


Вот казалось бы, эти товарищи могли выбрать для своего проекта любую технологию, хоть ASP, хоть JSP, хоть PHP. А выбрали в итоге RoR.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[8]: минусы Ruby
От: Mamut Швеция http://dmitriid.com
Дата: 28.07.06 08:35
Оценка:
E>Вот казалось бы, эти товарищи могли выбрать для своего проекта любую технологию, хоть ASP, хоть JSP, хоть PHP. А выбрали в итоге RoR.

Пора отделять ветку

ИМХО — беспрецендентная скорость прототипирования и разработки, связанная, не в последнюю очередь, с Convention over Configuration. То есть, вместо горы конфигурационных файлов имеем один. Вместо ручной работы с рекордсетами имеет довольно грамотный ORM. Вместо борьбы с привязкой валидации, отслеживания пользователей и проч, имеем фильтры, хелперы и validate_* в моделях.

И, хотя похожие условия предоставляют (уже) многие (Catalyst, TurboGear, CakePHP), Ruby все же приятней , чем Perl, Python, PHP.

ИМХО
... << RSDN@Home 1.2.0 alpha rev. 647>> ... <<Ennio Morricone — Speakeasy>> ...


dmitriid.comGitHubLinkedIn
Re[9]: минусы Ruby
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 28.07.06 08:57
Оценка:
Здравствуйте, Mamut, Вы писали:

M>И, хотя похожие условия предоставляют (уже) многие (Catalyst, TurboGear, CakePHP), Ruby все же приятней , чем Perl, Python, PHP.


Вот это и есть самое интересное. Я когда для Mxx_ru язык выбирал то пробовал и Perl, и Python, и Tcl. Везде получалось более-менее одинаково, но на Ruby было приятнее Видимо как раз в этом и состоит его притягательность.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[11]: минусы Ruby
От: mogadanez Чехия  
Дата: 01.08.06 18:57
Оценка:
M>>такая же фигня с параметром "_" — человек первый раз видящий его хрен догадается что он значит.
WH>Ну ты блин сравнил... два сокращения с сотнями...

подожди.... я еще только введение в Немерле прочитал.
Re[16]: минусы Ruby
От: Mamut Швеция http://dmitriid.com
Дата: 02.08.06 06:35
Оценка:
M>Ты что с луны свалился? про Apple слышал когда нибудь? если ты на нем не работаешь это ни о чем не говорит, у нас в оффисе соотношение Win и Mac ~ 10 к 8

M>у многих наших клиентов вообще подавляющее засилие Mac'ов


Apple — это _очень_ маленький сегмент рынка. Всего 4,6% штатовсого рынка — основного потребителя Макинтошей.
... << RSDN@Home 1.2.0 alpha rev. 655>> ... <<silent>> ...


dmitriid.comGitHubLinkedIn
Re[17]: минусы Ruby
От: FR  
Дата: 02.08.06 07:04
Оценка:
Здравствуйте, Mamut, Вы писали:

M>>Ты что с луны свалился? про Apple слышал когда нибудь? если ты на нем не работаешь это ни о чем не говорит, у нас в оффисе соотношение Win и Mac ~ 10 к 8


M>>у многих наших клиентов вообще подавляющее засилие Mac'ов


M>Apple — это _очень_ маленький сегмент рынка. Всего 4,6% штатовсого рынка — основного потребителя Макинтошей.


Читал в новостях что в этом году в штатах apple вышел по продажам на 11%.
По моему процент будет расти.
Re[17]: минусы Ruby
От: mogadanez Чехия  
Дата: 02.08.06 09:02
Оценка:
Здравствуйте, Mamut, Вы писали:

M>>Ты что с луны свалился? про Apple слышал когда нибудь? если ты на нем не работаешь это ни о чем не говорит, у нас в оффисе соотношение Win и Mac ~ 10 к 8


M>>у многих наших клиентов вообще подавляющее засилие Mac'ов


M>Apple — это _очень_ маленький сегмент рынка. Всего 4,6% штатовсого рынка — основного потребителя Макинтошей.


1. Там обзор по КОМПМАМ. MAC OS X теперь можно ставить теперь на Intel компы — так что процент операционок больше. + популярность должна расти.
2. плюс зависит от сферы деятельности, например в сфере GraphicArts — это один из самых популярных компов.
3. продаваемые Intel платформы в свою очередь тоже делятся на разные OS. так что Windows это не 95.4% а меньше
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Re[8]: минусы Ruby
От: kpumuk Украина http://kpumuk.info/
Дата: 02.08.06 10:06
Оценка:
Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>Дисклямер: сам не пробовал, бо мой Celeron900 VS2005 не потянет.


Я пробовал, при попытке конвертил существующий проект. После этого он не открывался.
На новом проекте работает, но не впечатлило... RadRails нааамного лучше в этом плане.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[18]: минусы Ruby
От: Mamut Швеция http://dmitriid.com
Дата: 02.08.06 10:22
Оценка:
M>>>Ты что с луны свалился? про Apple слышал когда нибудь? если ты на нем не работаешь это ни о чем не говорит, у нас в оффисе соотношение Win и Mac ~ 10 к 8

M>>>у многих наших клиентов вообще подавляющее засилие Mac'ов


M>>Apple — это _очень_ маленький сегмент рынка. Всего 4,6% штатовсого рынка — основного потребителя Макинтошей.


M>1. Там обзор по КОМПМАМ. MAC OS X теперь можно ставить теперь на Intel компы — так что процент операционок больше. + популярность должна расти.


На специально заточенные под МакОсь компы. Причем настолько специально, что Эпплу под давлением общественности пришлось выпускать патч, позволяющий ставить и Винду на те же компы.

M>2. плюс зависит от сферы деятельности, например в сфере GraphicArts — это один из самых популярных компов.


Не спорю. Но мы же говорим об общей доле рынка Потому что, например, в Вебе Микрософта вообще только 26 процентов. Правда, Эппла там совсем нет

M>3. продаваемые Intel платформы в свою очередь тоже делятся на разные OS. так что Windows это не 95.4% а меньше


Это естественно.
... << RSDN@Home 1.2.0 alpha rev. 655>> ... <<Tower Rowan — Avallon>> ...


dmitriid.comGitHubLinkedIn
Re[19]: минусы Ruby
От: mogadanez Чехия  
Дата: 02.08.06 10:39
Оценка:
M> На специально заточенные под МакОсь компы. Причем настолько специально, что Эпплу под давлением общественности пришлось выпускать патч, позволяющий ставить и Винду на те же компы.

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

ограничения есть в чипесете материнской платы( > 925 ), и то я не уверен что это ограничение, возможно просто _рекомендуемое_ железо.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Re[20]: минусы Ruby
От: Mamut Швеция http://dmitriid.com
Дата: 02.08.06 11:24
Оценка:
M>> На специально заточенные под МакОсь компы. Причем настолько специально, что Эпплу под давлением общественности пришлось выпускать патч, позволяющий ставить и Винду на те же компы.

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


M>ограничения есть в чипесете материнской платы( > 925 ), и то я не уверен что это ограничение, возможно просто _рекомендуемое_ железо.


Можно тогда ткнуть пальцем в то место, где можно скачать/купить официальный MacOS X для PC. Но такой MacOS X, который

а) Не является VMWare files for patched Mac OS X Tiger Intel

б) Не требует эмулятора PearPC

c) Не требует VmWare

Если бы MacOS можно было бы установить на любой комп, я бы его уже себе установил.
... << RSDN@Home 1.2.0 alpha rev. 655>> ... <<Tower Rowan — Avallon>> ...


dmitriid.comGitHubLinkedIn
Re[21]: минусы Ruby
От: mogadanez Чехия  
Дата: 02.08.06 11:39
Оценка:
C>Вранье. Есть взломанная версия Mac OS X, в которой убрана
C>проверка оборудования.

C>Родная Mac OS X не ставится на обычные компьютеры. А в EULA у них

C>прописано, кстати, что запрещено ставить Mac OS на компьютеры, не
C>сертифицированные Apple'ом.

да, но в статистику такие компы тоже должны попадать.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Re[15]: минусы Ruby
От: Mamut Швеция http://dmitriid.com
Дата: 04.08.06 08:25
Оценка:
K>По моему скромному разумению, такие средства как pattern-matching или там list comprehentions как раз и делают код (за исключением особо навороченных случаев) понятным любому человеку изучавшему алгебру в школе.

Дело в том, что зачастую между алгеброй в школе и знакомством с pattern matching'ом или list comprehensions проходит довольно много времени

K>Собственно говоря, человек, увидивший пример с pattern-matching — уже в какой-то степени знаком с pattern-matching.


Это верно.

K>Вот что, например, непонятного здесь:

K>
K>fac 0 = 1
K>fac n = n * fac (n-1)
K>


K>Или здесь:

K>
K>fac n = product [1..n]
K>


Ну, это простейшие примеры, которые понятны сразу. А вот уже простейший list comprehension, например:
sort([Pivot|T]) ->
    sort([ X || X <- T, X < Pivot]) ++
    [Pivot] ++
    sort([ X || X <- T, X >= Pivot]);
sort([]) -> [].

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

Единственное — синтаксис к этому не имеет ни малейшего отношения

ЗЫ. Мне кажется, любого, кому не нравится тот или иной синтаксис, надо насильно протащить через Lisp, Haskell и Erlang. Хотя бы на уровне "почитать туториалы". Потом на синтаксис перестаешь хоть какое-то внимание
... << RSDN@Home 1.2.0 alpha rev. 655>> ... <<James Last — March Of The Toreadors From "C>> ...


dmitriid.comGitHubLinkedIn
Re[16]: минусы Ruby
От: Klapaucius  
Дата: 04.08.06 12:40
Оценка:
Здравствуйте, Mamut, Вы писали:

K>>По моему скромному разумению, такие средства как pattern-matching или там list comprehentions как раз и делают код (за исключением особо навороченных случаев) понятным любому человеку изучавшему алгебру в школе.

M>Дело в том, что зачастую между алгеброй в школе и знакомством с pattern matching'ом или list comprehensions проходит довольно много времени

Ну, мне всегда казалось, что программисту в той или иной степени приходится сталкиваться с математикой. Хотя...

M>Ну, это простейшие примеры, которые понятны сразу. А вот уже простейший list comprehension, например:

M>
M>sort([Pivot|T]) ->
M>    sort([ X || X <- T, X < Pivot]) ++
M>    [Pivot] ++
M>    sort([ X || X <- T, X >= Pivot]);
M>sort([]) -> [].
M>

M>вызывает долгие ковыряния в мозгах и попытку вспомнить алгебру десятелетней давности

Это qsort! Я узнал его! Хотя это если и не первые строчки кода на Erlang, которые мне довелось увидеть, то по крайней мере, я могу точно сказать, что приходится смотреть код на Erlang мне очеь не часто. Если бы не ссылка, я бы его и не узнал.
Это, в общем, тоже простейший пример. Но речь как раз и идет о простых примерах, которые объявляются якобы непонятными.

M>Единственное — синтаксис к этому не имеет ни малейшего отношения


О чем и речь.

M>ЗЫ. Мне кажется, любого, кому не нравится тот или иной синтаксис, надо насильно протащить через Lisp, Haskell и Erlang. Хотя бы на уровне "почитать туториалы". Потом на синтаксис перестаешь хоть какое-то внимание


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

Собственно речь-то о том, что я — будучи, как функциональный программист, без малого пустым местом, не заметил у себя каких либо сложностей с восприятием. Правда, если это был не квиксорт, я признаю свое полное поражение и обязательно накажу себя трудом.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[17]: минусы Ruby
От: Mamut Швеция http://dmitriid.com
Дата: 05.08.06 07:59
Оценка:
K>Собственно речь-то о том, что я — будучи, как функциональный программист, без малого пустым местом, не заметил у себя каких либо сложностей с восприятием. Правда, если это был не квиксорт, я признаю свое полное поражение и обязательно накажу себя трудом.

Это был quicksort
... << RSDN@Home 1.2.0 alpha rev. 655>> ... <<silent>> ...


dmitriid.comGitHubLinkedIn
Re: минусы Ruby
От: Lloyd Россия  
Дата: 07.08.06 23:44
Оценка:
Здравствуйте, Курилка, Вы писали:

К>Собственно хотел предложить для прочтения (и обсуждения тоже) статью 5 things I hate about Ruby

К>Особенно не положительным 4-й пункт кажется: навязываемый "Ruby Way", который ещё и не имеет однозначной трактовки.
К>З.Ы. Как-то не нашёл куда логичнее будет это написать: руби почти насквозь императивный, поэтому в декларативные не лезет, а среди языков его нет...

Недетский глумеж: Report from OSCON2006: The Ruby Conspiracy
Re[2]: минусы Ruby
От: Пацак Россия  
Дата: 07.03.07 16:44
Оценка:
Здравствуйте, eao197 и все остальные

Ладно, ладно, уговорили, блин! Качаю!

PS Хотя питон мне все равно пока нравится больше
Ку...
Re[4]: минусы Ruby
От: Lloyd Россия  
Дата: 07.03.07 17:39
Оценка:
Здравствуйте, eao197, Вы писали:

П>>PS Хотя питон мне все равно пока нравится больше


E>Может быть вот это
Автор: Евгений Охотников
Дата: 03.03.07
склонит чашу весов в сторону Ruby?

E>)

Оглавление?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[4]: минусы Ruby
От: Anton Batenev Россия https://github.com/abbat
Дата: 09.03.07 08:31
Оценка:
Здравствуйте, eao197, Вы писали:

VD>>отсуствие полноценной IDE (комплит, рефакториг, ...),

E>Да есть IDE для Ruby, как open-source (FreeRDE, Mongrel, RDT), так и коммерческие (Komodo).
E>Более того, Rubyist-ов совсем это не парит. Большинство используют VIM, emacs и TextMate (под MacOS), не испытывая при этом никаких сожалений.

Меня это парит. И, честно говоря, чем дальше, тем больше. Все IDE, к сожалению, времени пересмотреть не было. Сейчас работаю на эклипсе. Про полноценную отладку можно забыть — часик ждешь, пока программа дойдет до брекпоинта и при этом еще не всегда понятно — вошла ли IDE в режим отладки или нет.

По этому, если кто подскажет IDE с нормальным отладчиком, комплитом и средствами рефакторинга (бесплатную естественно) буду премного благодарен, т.к. сейчас трачу огромное количество времени на банальные вещи типа переименовывания, расставления отступов и разбора отладочной информации, которую приходится выводить на экран.
Re[9]: минусы Ruby
От: cl-user  
Дата: 17.03.07 08:42
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Ну, да. Видишь как народ толпами ломится за счастьем? И я нет. Видимо он тупой. Самое время вспомнить что-то вроде "силлионы мух не могут ошибиться...".


Да не важно, тупой ли он и ошибается или нет — важно, что на большей толпе можно сделать больше бабла. А здесь уже "правят бал" маркетинг и прочие методы влияния на эту самую толпу. Техническая сторона дела — далеко не на первом месте. Хотя обкатка на толпе может давать неплохие результаты даже в техническом плане.
Re[10]: минусы Ruby
От: Quintanar Россия  
Дата: 17.03.07 15:51
Оценка:
Здравствуйте, mogadanez, Вы писали:

M>а почему тогда в том же немерле def означает define?

M>почему сократили? почему не полностью define? ведь если я первый раз вижу код на немерле и не писал на языках где есть def, я могу и с default перепутать, или с defolt

M>такая же фигня с параметром "_" — человек первый раз видящий его хрен догадается что он значит.


Мануал почитать не судьба?
Re[10]: минусы Ruby
От: VladD2 Российская Империя www.nemerle.org
Дата: 17.03.07 16:58
Оценка:
Здравствуйте, mogadanez, Вы писали:

M>а почему тогда в том же немерле def означает define?

M>почему сократили? почему не полностью define? ведь если я первый раз вижу код на немерле и не писал на языках где есть def, я могу и с default перепутать, или с defolt

M>такая же фигня с параметром "_" — человек первый раз видящий его хрен догадается что он значит.


Согласись, что запомнить два соглашения несколько проще чем 222.
Учитывая частоту применения сокрашение def и _ оправданы. А вот сокращать методы в библиотеках — это порочный путь.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: минусы Ruby
От: Ligen Украина http://zone-of-ambiguity.blogspot.com/
Дата: 06.11.07 17:21
Оценка:
Здравствуйте, Kluev, Вы писали:

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


K>А что длжно быть как в винде?

K>
DoSomethingByLeftHandEatShitAndDie


ах да, конечно, тру пацаны называют функции исключительно в таком ключе:
FindLFNorSFN_U
mkstemp
shmdt


я выбрал их совершенно cлучайно.
Какаие шансы, не заходя в гугл, по названию, узнать что они делают? хотя бы область применения?
Viva el Junta Militar! Viva el Presidente!
Возвращаясь к вопросу :)
От: Left2 Украина  
Дата: 07.11.07 11:15
Оценка:
Тема всплыла и решил добавить

K>И чего же удобного? все сделано через ж-пу. Чтобы банальные вещи в файловой системе сделать надо FileSystemObject создавать.


K>вот bash это действительно удобная альтерантива бат-файлам.

А для bash есть отладчик? Сделать FileSystemObject-обьект — это не так уж и критично, если скрипт будет занимать хотя бы пол-экрана. Зато в нашем распоряжении очень даже неслабый язык программирования (JavaScript forever ) с удобнейшим отладчиком. bash-скрипты имеют тенденцию разрастаться, и тут уже читаемость и отлаживаемость выходят на первый план, перевешивая лаконичность. Вообщем, моё мнение — если target-платформа ограничена Windows, то использование WScript очень даже себя оправдывает.
... << RSDN@Home 1.2.0 alpha rev. 717>>
To moderator
От: Left2 Украина  
Дата: 07.11.07 11:16
Оценка:
Сорри, предупреждение увидел после того как ответ написал А можно выделить это в отдельную подветку?
... << RSDN@Home 1.2.0 alpha rev. 717>>
Re[2]: Возвращаясь к вопросу :)
От: Left2 Украина  
Дата: 07.11.07 11:57
Оценка:
L>>Вообщем, моё мнение — если target-платформа ограничена Windows, то использование WScript очень даже себя оправдывает.
C>Я как-то очень долго искал как работать из WScript с файлом в бинарном режиме. Ответ: НИКАК.
Ну на крайняк — через сторонний компонент, благо таковой пишется за пол-часа

C>Вообще, я для больших скриптов использую Python — в нем намного более удобная работа с файлами и каталогами, чем через FSO.

Да, достойная альтернатива. Из минусов — питон за собой таскать нужно, а WScript на виндовых машинах всегда есть.
... << RSDN@Home 1.2.0 alpha rev. 717>>
Re[3]: Возвращаясь к вопросу :)
От: Cyberax Марс  
Дата: 08.11.07 04:08
Оценка:
Left2 wrote:
> C>Я как-то очень долго искал как работать из WScript с файлом в бинарном
> режиме. Ответ: НИКАК.
> Ну на крайняк — через сторонний компонент, благо таковой пишется за
> пол-часа
Ага. Но потом этот компонент еще надо будет везде ставить и
регистрировать (права админа нужны будут).

> C>Вообще, я для больших скриптов использую Python — в нем намного более

> удобная работа с файлами и каталогами, чем через FSO.
> Да, достойная альтернатива. Из минусов — питон за собой таскать нужно, а
> WScript на виндовых машинах всегда есть.
Питоновский скрипт при желании можно упаковать в автономный exe-шник, в
котором будет лежать интерпретатор Питона и все нужные библиотеки. Очень
полезная фича, кстати.
Posted via RSDN NNTP Server 2.1 beta
Sapienti sat!
Re[4]: Возвращаясь к вопросу :)
От: Left2 Украина  
Дата: 09.11.07 10:00
Оценка:
>> Ну на крайняк — через сторонний компонент, благо таковой пишется за
>> пол-часа
C>Ага. Но потом этот компонент еще надо будет везде ставить и
C>регистрировать (права админа нужны будут).
Если не нужна поддержка дремучей NT 4.0 — то права админа необязательны, можно регистрироваться только для конкретного юзера.

C>Питоновский скрипт при желании можно упаковать в автономный exe-шник, в

C>котором будет лежать интерпретатор Питона и все нужные библиотеки. Очень
C>полезная фича, кстати.
Интересно, не знал такого, спасибо.
... << RSDN@Home 1.2.0 alpha rev. 717>>
Re[14]: минусы Ruby
От: elmal  
Дата: 12.11.07 14:26
Оценка:
Здравствуйте, Mamut, Вы писали:

M>Для человека, незнакомого с pattern-matching'ом, здесь непонятно все

Выражу несогласие . Вроде я не особо знаю, что такое pattern-matching, но насколько я понял — код делает преобразование целого числа в строку. Слева описаны целые значения, справа строковые . Аналог switch.case, _ в данном случае будет default . Угадал ?
Re[15]: минусы Ruby
От: VladD2 Российская Империя www.nemerle.org
Дата: 06.12.07 10:49
Оценка:
Здравствуйте, elmal, Вы писали:

E>Выражу несогласие . Вроде я не особо знаю, что такое pattern-matching, но насколько я понял — код делает преобразование целого числа в строку. Слева описаны целые значения, справа строковые . Аналог switch.case, _ в данном случае будет default . Угадал ?


Угадал. Но бывают и куда более сложные случаи.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.