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
От: 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[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
От: 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[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[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
Оценка: 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[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[15]: минусы Ruby
От: FR  
Дата: 04.06.06 15:04
Оценка: +1
Здравствуйте, VladD2, Вы писали:


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


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

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


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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.