Я не собирался публиковать это как ответ, но Xeoncross попросил меня, так что здесь мы идем:
(Примечание: если бы кто-то мог исправить проблему уценки в небольшом примере кода, я был бы признателен.)
Эрик Макс Фрэнсис написал:
«Брэндон Дж. Ван Эвери» писал:
Что лучше в Ruby, чем в Python? Я уверен, что что-то есть. Что это? Разве не было бы гораздо больше смысла спрашивать об этом у людей с Ruby, а не у людей с Python?
Может или не может, в зависимости от своих целей - например, если в чьи-то цели входит «социологическое исследование» сообщества Python, то постановка вопросов этому сообществу, скорее всего, окажется более показательной для информации, чем размещение их в другом месте. :-). Лично я с радостью воспользовался возможностью, чтобы последовать однодневному уроку Дэйва Томаса по Ruby на прошлой группе. Ниже тонкого слоя различий в синтаксисе я нахожу, что Ruby и Python удивительно похожи - если бы я вычислял минимальное связующее дерево практически для любого набора языков, я почти уверен, что Python и Ruby будут первыми двумя листами, которые объединятся в промежуточный узел :-).
Конечно, я устать, в Ruby, чтобы печатать глупый «конец» в конце каждого блока (а не просто unindenting) - но тогда я получить , чтобы избежать печатая одинаково глупы , :
который Python требует в
начале из каждый блок, так что это почти мытье :-). Другие различия в синтаксисе, такие как « @fooпротив»
self.fooили более высокая значимость падежа в «Ruby vs Python», действительно для меня почти не имеют значения.
Другие, без сомнения, основывают свой выбор языков программирования именно на таких проблемах, и они вызывают самые горячие споры - но для меня это всего лишь пример одного из законов Паркинсона в действии (количество споров по проблеме обратно пропорционально актуальное значение). Одно из синтаксических различий, которое я считаю важным, и в пользу Python - но другие люди, несомненно, будут думать об обратном - это «как вызвать функцию, которая не принимает параметров». В Python (как в C) для вызова функции вы всегда применяете «оператор вызова» - завершающие скобки сразу после вызываемого объекта (внутри этих завершающих скобок идут аргументы, которые вы передаете в вызове - если вы не передаете аргументы, тогда круглые скобки пусты). Это оставляет простое упоминание любого объекта без участия оператора как означающее просто ссылку на объект - в любом контексте, без особых случаев, исключений, специальных правил и тому подобного. В Ruby (как в Pascal) для вызова функции WITH с аргументами вы передаете аргументы (обычно в круглых скобках, хотя это не всегда так) - НО, если функция не принимает аргументов, тогда просто упоминание функции неявно вызывает ее. Это может соответствовать ожиданиям многих людей (по крайней мере, без сомнения, тех, чей единственный предыдущий опыт программирования был с Pascal или другими языками с похожим «вызовом implcit», таким как Visual Basic) - но для меня это означает простое упоминание объекта может означать ЛИБО ссылку на объект ИЛИ вызов объекта, в зависимости от типа объекта - и в тех случаях, когда я не могу получить ссылку на объект, просто упомянув его, мне нужно будет использовать явное «дайте мне ссылку на это, НЕ называйте это!» операторы, которые не нужны в противном случае. Я чувствую, что это влияет на «первоклассность» функций (или методов, или других вызываемых объектов) и возможность плавного обмена объектами. Поэтому для меня это специфическое различие в синтаксисе является серьезной черной чертой против Ruby, но я понимаю, почему другие поступили бы иначе, даже если бы я едва ли мог с ними более не согласиться :-). Ниже синтаксиса мы обнаруживаем некоторые важные различия в элементарной семантике - например, строки в Ruby являются изменяемыми объектами (как в C ++), в то время как в Python они не изменяемы (как в Java, или я верю C #). Опять же, люди, которые судят в первую очередь по тому, с чем они уже знакомы, могут подумать, что это плюс для Ruby (если, конечно, они не знакомы с Java или C # :-). Я, я думаю, что неизменяемые строки - отличная идея (и я не удивлен, что Java, независимо, я думаю, заново изобрел эту идею, которая уже была в Python), хотя я также не возражаю против использования типа «изменяемый строковый буфер» (и, в идеале, более простой в использовании, чем собственные строковые буферы Java); и я не даю это суждение из-за знакомства - до изучения Java, кроме функциональных языков программирования, где люди, которые судят в первую очередь по тому, с чем они уже знакомы, могут подумать, что это плюс для Ruby (если, конечно, они не знакомы с Java или C # :-). Я, я думаю, что неизменяемые строки - отличная идея (и я не удивлен, что Java, независимо, я думаю, заново изобрел эту идею, которая уже была в Python), хотя я также не возражаю против использования типа «изменяемый строковый буфер» (и, в идеале, более простой в использовании, чем собственные строковые буферы Java); и я не даю это суждение из-за знакомства - до изучения Java, кроме функциональных языков программирования, где люди, которые судят в первую очередь по тому, с чем они уже знакомы, могут подумать, что это плюс для Ruby (если, конечно, они не знакомы с Java или C # :-). Я, я думаю, что неизменяемые строки - отличная идея (и я не удивлен, что Java, независимо, я думаю, заново изобрел эту идею, которая уже была в Python), хотя я также не возражаю против использования типа «изменяемый строковый буфер» (и, в идеале, более простой в использовании, чем собственные строковые буферы Java); и я не даю это суждение из-за знакомства - до изучения Java, кроме функциональных языков программирования, где Я думаю, что неизменяемые строки - отличная идея (и я не удивлен, что Java, независимо от этого, я думаю, заново изобрел эту идею, которая уже была в Python), хотя я также не возражаю против использования типа «изменяемый строковый буфер» (и в идеале, с лучшей простотой использования, чем собственные строковые буферы Java); и я не даю это суждение из-за знакомства - до изучения Java, кроме функциональных языков программирования, где Я думаю, что неизменяемые строки - отличная идея (и я не удивлен, что Java, независимо от этого, я думаю, заново изобрел эту идею, которая уже была в Python), хотя я также не возражаю против использования типа «изменяемый строковый буфер» (и в идеале, с лучшей простотой использования, чем собственные строковые буферы Java); и я не даю это суждение из-за знакомства - до изучения Java, кроме функциональных языков программирования, гдевсе данные являются неизменяемыми, все языки, которые я знал, имели изменяемые строки - однако, когда я впервые увидел идею неизменяемой строки в Java (которую я выучил задолго до изучения Python), она сразу показалась мне превосходной, очень хорошо подходящей для эталонная семантика языка программирования более высокого уровня (в отличие от семантики значений, которая лучше всего подходит для языков ближе к машине и дальше от приложений, таких как C) со строками в качестве первоклассного, встроенного (и довольно решающее значение) тип данных.
У Ruby есть некоторые преимущества в элементарной семантике - например, удаление «списков против кортежей» в Python чрезвычайно тонкое различие. Но в основном счет (как я считаю, с простотой большой плюс и тонкие, умные различия заметным минусом) против Ruby (например, с закрытыми и полуоткрытыми интервалами, с обозначениями a..b и a .. .b [кто-нибудь хочет утверждать, что очевидно, что есть что? -)], глупо - ИМХО, конечно!). Опять же, люди, которые считают, что в основе языка заложено много схожих, но слегка отличающихся друг от друга вещей, ПЛЮС, а не МИНУС, будут, конечно, считать это «наоборот» из того, как я их считаю :-).
Не вводить в заблуждение этих сравнений, думая , что два языка
оченьразные, заметьте. Это не так. Но если бы меня попросили сравнить «capelli d'angelo» с «спагеттини», указав, что эти два вида макаронных изделий практически ни для кого не различимы и взаимозаменяемы в любом блюде, которое вы, возможно, захотите приготовить, я бы неизбежно перейти к микроскопическому исследованию того, как длины и диаметры незаметно различаются, как концы нитей сужаются в одном случае, а не в другом, и т. д., чтобы попытаться объяснить, почему я лично предпочел бы иметь капеллу. 'angelo как макароны в любом виде бульона, но предпочел бы спагеттини в качестве pastasciutta идти с подходящими соусами для таких длинных тонких форм пасты (оливковое масло, рубленый чеснок, рубленый красный перец и мелко нарезанные анчоусы, например - но если вы нарезали чеснок и перец вместо того, чтобы их измельчать, то вам следует выбрать более твердое тело спагетти, а не более тонкую мимолетную спагеттини, и было бы хорошо отказаться от просмотра и добавить вместо этого свежий весенний базилик [ или даже - я еретик ...! - легкая мята ...] листья - в самый последний момент перед подачей блюда). Упс, извините, это показывает, что я еду за границу и у меня не было пасты некоторое время, я думаю. Но аналогия все еще довольно хороша! -) и я бы посоветовал отказаться от просмотра и добавить вместо этого свежий весенний базилик [или даже - я еретик ...! - легкая мята ...] листья - в самый последний момент перед подачей блюда). Упс, извините, это показывает, что я еду за границу и у меня не было пасты некоторое время, я думаю. Но аналогия все еще довольно хороша! -) и я бы посоветовал отказаться от просмотра и добавить вместо этого свежий весенний базилик [или даже - я еретик ...! - легкая мята ...] листья - в самый последний момент перед подачей блюда). Упс, извините, это показывает, что я еду за границу и у меня не было пасты некоторое время, я думаю. Но аналогия все еще довольно хороша! -)
Итак, вернемся к Python и Ruby, мы подошли к двум важным аспектам (с точки зрения собственно языка - оставление библиотек и других важных вспомогательных элементов, таких как инструменты и среды, как встраивать / расширять каждый язык и т. Д. И т. Д.). это пока - они не будут применяться ко всем РЕАЛИЗАЦИЯМ каждого языка в любом случае, например, Jython vs Classic Python - это две реализации языка Python!):
Итераторы и кодовые блоки Ruby против итераторов и генераторов Python;
ОБЩАЯ, безудержная «динамичность» Руби, включая возможность «вновь открывать» любой существующий класс, включая все встроенные, и изменять его поведение во время выполнения - по сравнению с обширной, но ограниченной
динамикой Python , которая никогда не меняет поведение существующих встроенные классы и их экземпляры.
Лично я считаю 1 стиркой (различия настолько глубоки, что я легко могу видеть, как люди ненавидят любой подход и меняют друг друга, но в МОИХ личных масштабах плюсы и минусы почти сглаживаются); и [2] решающий вопрос - тот, который делает Ruby гораздо более подходящим для «переделок», НО Python в равной степени более подходящим для использования в крупных производственных приложениях. Забавно, в некотором смысле, потому что оба языка настолько НАМНОГО более динамичны, чем большинство других, что в конечном итоге ключевое отличие между ними от моего POV должно зависеть от этого - что Ruby «идет в одиннадцать» в этом отношении (ссылка вот к "Spinal Tap", конечно). В рубинеЯ могу сделать это ! Т.е. я могу динамически изменять встроенный класс строки так, чтобы
a = "Hello World"
b = "Привет, мир"
если а == б
напечатать "равно! \ n"
еще
распечатать "разные! \ n"
конец
БУДЕТ печатать «равный». В питоне НЕТ, как я могу это сделать. В целях метапрограммирования, реализации экспериментальных сред и т. П. Эта удивительная динамическая способность Ruby чрезвычайно
привлекательным. НО - если мы говорим о больших приложениях, разработанных многими людьми и поддерживаемых еще большим количеством, включая всевозможные библиотеки из разных источников, и нуждающихся в запуске на клиентских сайтах ... ну, я не ХОЧУ язык, который довольно динамичен, большое спасибо. Я ненавижу саму идею о том, что какая-то библиотека невольно ломает другие несвязанные, которые полагаются на то, что эти строки различны - это своего рода глубоко и глубоко скрытый «канал», между кусками кода, которые СМОТРЯ разделяют, и ДОЛЖНЫ БЫТЬ отделенными, что означает смерть в масштабное программирование. Позволяя любому модулю «скрытно» влиять на поведение любого другого,
Если бы мне пришлось использовать Ruby для такого большого приложения, я бы постарался опираться на ограничения стиля кодирования, множество тестов (для повторного запуска всякий раз, когда НИЧЕГО изменится - даже то, что должно быть совершенно не связано ...) и тому подобное, запретить использование этой языковой функции. Но НЕ иметь эту функцию, во-первых, еще лучше, на мой взгляд, так же, как сам Python был бы еще лучшим языком для разработки приложений, если бы определенное количество встроенных элементов могло быть «прибито», поэтому я ЗНАЛ, что Например,
len("ciao")это 4 (вместо того, чтобы подсознательно беспокоиться о том, изменил ли кто-нибудь привязку имени lenв __builtins__
модуле ...). Я действительно надеюсь, что в конечном итоге Python «приметит» свои встроенные модули.
Но проблема незначительна, поскольку повторное связывание встроенных модулей является устаревшим, а также редкой практикой в Python. В Ruby это кажется мне главным - так же, как слишком мощные
средства макросов других языков (таких как, скажем, Dylan) представляют аналогичные риски по моему собственному мнению (я надеюсь, что Python никогда не получит такую мощную систему макросов, нет Независимо от того, «позволять ли людям определять свои собственные предметно-ориентированные маленькие языки, встроенные в сам язык», - это, IMHO, подорвало бы замечательную полезность Python для разработки приложений, представив «привлекательную неприятность» потенциальному тинкеру, который таится в сердце каждого программиста ...).
Alex