минусы Ruby - Философия программирования

Здравствуйте, 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 и статически типизированные языки действительно рулят.

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>>

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>>

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

Здравствуйте, 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>В общем, документацию читать все равно придется...

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

Здравствуйте, 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

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

VD>Кстати, поймал себя на мысли, что чаще открываю Рефлектор, чем МСДН.

Таж фигня. Увы, качество документации никакое, сырцов нету. Вот и приходится с рефлектором карячиться. Вот с jdk сразу сырцы идут — рефлектор не нужен.

http://www.smalltalk.ru | << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, 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>Во истину о вкусах не спорят.

Если так то нет

Но если взять первоначальные два куска кода то наооборот

Здравствуйте, 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.

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

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

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

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Таж фигня. Увы, качество документации никакое, сырцов нету. Вот и приходится с рефлектором карячиться. Вот с jdk сразу сырцы идут — рефлектор не нужен.

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