про руби (программистское)

[avva]

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

Обычное дело - когда о чем-то очень громко говорят, выходит, что говорят в основном дураки. А что поделать, если хочется быть услышанным?

В последнее время мне попались два примера.

What's Wrong With Ruby - мнение человека, которому не очень понравился Руби. В статье он перечисляет, что ему не понравилось и что показалось перехваленным в обычных описаниях Руби. При этом он сохраняет вполне корректный и умеренный тон, и отдает должное языку в том, что ему понравилось. Интересная статья, несколько эклектичная и недостаточно подробная, но все равно интересная. Я, например, разделяю неприязнь автора к "cutesy introductory tutorials", и особенно к знаменитому в сообществе Руби Why's (Poignant) Guide. Это ужасная на мой взгляд книга, полная несмешных вымученных шуток и картинок, идиотской болтовни, и на редкость неудачных собственно объяснений и примеров того, что касается самого языка.

Однако дело не столько в самой статье, сколько в комментариях под ней, в которых тут же собралось стадо fanboys - идиотов, ругающих автора последними словами за то, что он посмел посягнуть на их культовый язык или на культовую фигуру _why (автора вышеупомянутой книги). Их немало в комментариях к самой статье, и еще больше - в комментариях к записи _why на эту тему (как обычно в его стиле, зубодробительно несмешной). Почитайте - эти комментарии говорят за себя. Нет, я не думаю, что они характеризуют все сообщество пользователей Руби. Но они характеризуют то стадо fanboys, которое его замусорило.

Мне попадалось мнение, что идиоты кочуют от одного популярного языка или технологии к другим, и многие из тех, что сейчас пишут и говорят благоглупости о Руби, раньше молились на Джаву, когда та была "cool". Может, в этом что-то есть. Но что в языке или технологии или сообществе, уже существующем, притягивает такие массы? Я не могу себе представить, например, такой поток ответов на статью, критикующую Перл, ни сейчас, ни пять лет назад, ни десять. Или Питон, или Хаскель, или Лисп.

Второй пример - статья "Why was Rails only possible with Ruby?" на сайте O'Reilly. Точнее, не статья, а рецензия книги о Руби и Rails. В ней самой, и в довольно интересно потоке комментариев под ней, поражает совершенное детская наивность тех, кто упрямо утверждает, что в Руби есть какие-то мистические свойства, которые делают создание системы типа Rails возможным только в Руби - и их неспособность назвать эти свойства: после того, как им снова и снова объясняют, что вот эти и вот эти и вот эти свойства Руби, которые они считают уникальными, на самом деле есть и тут и тут и тут, и системы, подобные Rails, на самом деле есть, и в чем-то более интересные (Seaside в Смоллтоке часто упоминается в последнее время - я не успел пока о нем подробнее прочитать), после всего этого им остается только лепет насчет "интуитивности" и каких-то мистических откровений, которые превращают Руби в идеальнейший из языков. Пользуясь словами того же _why, "We can no longer truthfully call it a computer language. It is coderspeak. It is the language of our thoughts". И вот такой интеллектуально беспомощный фанатизм тоже, увы, весьма распостранен в сообществе Руби, насколько я могу судить, когда с ним сталкиваюсь. Впрочем, опять-таки, действительно ли "увы"? Может, сообществу Руби это нравится, и такая форма агрессивного самопиара его вполне устраивает.

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

"Can't we all at least agree to hate PHP? ;)"

Comments

[netch]

У перла слишком сильно его прошлое в виде patologically eclectical rubbish lister. Вследствие этого тяжёлый синтаксис в более серьёзных применениях, чем переработка входа в выход, масса умолчаний и исключений, которые в большом количестве кода начинают смущать и задалбывать... Странные решения, когда (@a, @b) становится конкатенацией списков, а если хочешь использовать ссылки начинаешь путаться во вложенностях... Да, после С/C++ он терпим. После чего-то более "с человеческим лицом" вроде Питона - на перле очень тяжело писать.

На днях надо было сделать в одном шкрипте преобразование с фильтрацией и переработкой строк. Упрощая задачу до учебного вида, в Питоне это вылилось бы во что-то в виде [s.rstrip('\r\n') for s in f.readlines() if s.match('^[a-z]')]. На перле я запутался в map(), хотя пару лет назад спокойно бы такое породил, и вместо этого нарисовал цикл... Понятно, что это говорит о том, что я обленился и "ниасилил", но ещё больше это показывает, как привыкаешь к хорошему и как тяжело возвращаться к извратным решениям...

[ninazino.livejournal.com]

[s.rstrip('\r\n') for s in f.readlines() if s.match('^[a-z]')]

На перле это может звучать так:

while(<>){
chomp;
next unless $_;
}

Ну и еще примерно ...надцатью способами можно выразить то же самое.

[netch]

Немного не так - в пределах того же учебного упрощения получается примерно так:

@o = ();
while(<F>) {
  chomp;
  push @o, $_ if /^[a-z]/;
}
## дальше как-то используем @o

Но Вы упустили главную мысль моего сообщения - что хотелось сделать то же самое через map+grep. С grep'ом просто - grep(/^[a-z]/, <F>) - а вот map чего-то не дался. Сейчас я уже понял - криво прочёл ман - надо было у функции внутри map искать не первый позиционный аргумент, а контекстное $_, в таком вот стиле:

@x = (1, 2, 3);
sub m_dd { return "$_.$_"; }
@o = map(&m_dd, @x);
print join(' ', @o), "\n";

ну а для исходной задачи получалось что-то вроде

sub m_chomp { my $x = $_; chomp $x; return $x; }
@o = map(&m_chomp, grep(/^[a-z]/, <F>));

с такими извратами в функции, потому что модифицировать исходный список - сомнительное удовольствие (в данном случае ещё можно себе позволить, но при переделке может вылезти боком).

Ну и ещё несколько странностей хотелось бы вспомнить - например, что в Питоне если вывести список через какой-нибудь print он выводится так, что можно понять и где какой элемент, например: "[1,2,3]", а в перле если вывести список (1,2,3) "напрямую" получается "123", через "@x" - "1 2 3" которое будет лажаться если в элементах есть пробелы... а для нормальной печати во внутреннем виде нужно вызывать специальные модули и помнить, как их использовать... при том, какой объём сейчас занимает обычная установка Перла это уже просто нелепо...

[dimrub.livejournal.com]

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

Что же касается мэпа в перле - да, не могу не согласиться, моим представлениям об интуитивности он совершенно не соответствует.

[netch]

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

Вы не учитываете специфику print: по сути, это отладочный оператор или оператор для построчного интерактивного взаимодействия. Для подобных его применений такое его поведение вполне осмысленно. Если нужно что-то другое - пожалуйста, sys.stdout.write() повторяет поведение сишного fputs() в точности, выводите что хотите безо всяких пробелов и переводов строки.

> Печатать без пробелов же можно, конечно, но на порядок сложнее

print "a=%s; b=%s' % (a, b)

это на порядок сложнее? я бы сказал - не более чем в 2 раза.

[dimrub.livejournal.com]

Вы не учитываете специфику print

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

Если нужно что-то другое - пожалуйста, sys.stdout.write()

Но он выводит только строку, значит мне еще и перевод в строку вручную придется делать, чего при использовании print делать не надо. Это не говоря уж о том, что когда у меня 20 мест в коде, которые должны печатать что-то, то std.stdout.write() - это несколько уродливо.

print "a=%s; b=%s' % (a, b)

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

это на порядок сложнее? я бы сказал - не более чем в 2 раза.

Пусть будет по-Вашему :).

[netch]

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

По крайней мере этот print соответствует по семантике классическому бейсиковскому и фортрановскому. А с чем ещё его сравнивать? С сишным printf? Ну так это не оператор, а функция.

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

А в Си, например, необходимость дописывать "\n" не смущает? Здесь надо определиться, какую из (минимум трёх) возможных семантик используем:
- fortran & basic - перевод строки происходит автоматически, чтобы его отменить надо применить синтаксическое уточнение
- pascal - перевод строки уточняется оператором (writeln вместо write; это не оператор, а особая функция, но суть та же) явно
- C - перевод строки делается явно особым символом

В Питоне, print следует первому, а write() - третьему.

> Это не говоря уж о том, что когда у меня 20 мест в коде, которые должны печатать что-то, то std.stdout.write() - это несколько уродливо.

Ну так определите себе "шорткат":

  w = sys.stdout.write
  w("Hello ")
  w('world\n')

благо язык позволяет такие вещи без проблем.

Так же можно сделать и аналог printf() (но надо делать это уже через def):

def printf(format, *args):
  sys.stdout.write(format % args)

и спокойно себе рисовать что-то в духе

  printf("Hello world! My name is %d\n", os.getpid())

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

Ну и не за один присест можно:

  print "a=%s;" % a,
  print "b=%s" % b

Впрочем, при таком стиле printf() полезнее.

> Пусть будет по-Вашему :).

Ага:) Я за print'ом обычно таки не гоняюсь. Хотя для отладочной печати он очень неплох.

[dimrub.livejournal.com]

По крайней мере этот print соответствует по семантике классическому бейсиковскому и фортрановскому.

Что-то не припомню, чтобы они вставляли пробел после каждого поля. Хотя, может, и вставляли - давно не брал в руки шашку :).

А с чем ещё его сравнивать? С сишным printf? Ну так это не оператор, а функция.

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

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

Ну так определите себе "шорткат":

Понятно, что я МОГУ это сделать. Вопрос, почему я ДОЛЖЕН это делать. Вопрос вкуса, конечно. Вкуса авторов языка (почему-то решивших, что у большинства пользователей после каждого поля обязательно нужен пробел) и пользователей (которые авторов не побили больно, а значит - довольны).

[netch]

> Что-то не припомню, чтобы они вставляли пробел после каждого поля. Хотя, может, и вставляли - давно не брал в руки шашку :).

Бейсиковский вставлял логическую табуляцию (выравнивание на колонку 1, 9, 17...) если разделение шло символом ',' и не вставлял, если ';'
Фортрановский не вставлял (FORMAT требовал явных пробелов).
Но я не про них, а про перевод строки в конце.

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

> Понятно, что я МОГУ это сделать. Вопрос, почему я ДОЛЖЕН это делать. Вопрос вкуса, конечно. Вкуса авторов языка (почему-то решивших, что у большинства пользователей после каждого поля обязательно нужен пробел) и пользователей (которые авторов не побили больно, а значит - довольны).

Наверно, они привыкли к идее получить ссылку на метод объекта.;)

[ninazino.livejournal.com]

@o = ();
while() {
chomp;
push @o, $_ if /^[a-z]/;
}

Ну да, я просто не прописывала всю задачу.

Но Вы упустили главную мысль моего сообщения - что хотелось сделать то же самое через map+grep

Собственно, именно это я и хотела спросить -- чем while-то плох? Я согласна, map действительно не очень интуитивен, хотя это дело привычки.

[netch]

> Собственно, именно это я и хотела спросить -- чем while-то плох?

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

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