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

Ruby - это динамический язык программирования с открытым исходным кодом, ориентированный на простоту и производительность.

Python - это язык программирования, который позволяет вам работать быстрее и более эффективно интегрировать ваши системы.

Будучи разработчиком PHP в течение многих лет, Вик Керубини хорошо подводит итог моего положения:

Я хорошо знал PHP, имел свой собственный фреймворк и мог быстро работать, чтобы что-то запустить и запустить.

Я так программировал всю революцию MVC. Я стал работать лучше и лучше (читай: лучше платить, лучше название) как разработчик PHP, но все время осознавая, что код, который я написал в свое время, был великолепен, а код, с которым я работал на работе, был ужасен. Мол хуже ужасного. Зверские. Уровень OS Commerce плохой. Наличие сторонних проектов поддерживало меня в здравом уме, потому что код, с которым я работал на работе, делал меня несчастным.

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

Языки, на которые я смотрел, включают JavaScript (для node.js), Ruby, Python и Erlang. Я даже думал о Scala или C ++.

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

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

Обновить

Я просто не хочу тратить 4 месяца в пути с каким-то языком и считаю, что это отстой, потому что каждый поток имеет 4 МБ служебных данных, или максимальное количество одновременных соединений составляет 999, нет пакета для выполнения функции "X" или поддержка постепенно сокращается для новой языковой ветви.

Я не собирался публиковать это как ответ, но Xeoncross попросил меня, так что здесь мы идем:

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

Автор Alex Martelli на comp.lang.python : Что лучше в Ruby, чем в Python? 18 августа 2003 г., 17:50

Эрик Макс Фрэнсис написал:

«Брэндон Дж. Ван Эвери» писал:

Что лучше в 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!):

1. Итераторы и кодовые блоки Ruby против итераторов и генераторов Python;

2. ОБЩАЯ, безудержная «динамичность» Руби, включая возможность «вновь открывать» любой существующий класс, включая все встроенные, и изменять его поведение во время выполнения - по сравнению с обширной, но ограниченной динамикой 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

Удачи

Ни одно из приведенных примеров не является объективным или проверяемым. Они все шумиха и мнения.

... простота и производительность ... быстрее ... эффективнее.

Попытайся

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

Я думаю, что часть проблемы заключается в том, что любой, кто знает достаточно, чтобы комментировать осмысленно об одном или нескольких языках, будет иметь тенденцию к предвзятости. За почти 4 десятилетия программирования я работал на большем количестве языков, чем могу сосчитать. Я могу дать вам мнения (некоторые из них датированы) относительно многих из этих языков, но ни одно из этих мнений не будет беспристрастным.

Я использую подход, использующий правильный язык для работы. Вы конкретно спрашиваете о веб-разработке , но это все еще довольно широкая категория - вроде как сказать, что вы заинтересованы в фотографии. Микро? Astro? и т. д. Хотя я согласен, что для многих клиентов PHP не является эмоционально насыщенным языком для работы это правильный язык, основанный на любом количестве факторов, не в последнюю очередь это долгосрочная способность находить программистов для исправления сайта после вашего ухода и / или попасть под автобус.

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

питон

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

• Django - полноценный, зрелый высокоуровневый фреймворк с усовершенствованным ORM, системой шаблонов, обработкой форм и т. Д.
• Twisted - фреймворк для событийного (асинхронного) сетевого программирования, его можно использовать для чатов, серверов сокетов, веб-сервисов.
• Tornado - также управляемый событиями фреймворк, но этот предназначен для асинхронных веб-сервисов.

Рубин

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

JavaScript

В настоящее время единственным выбором на стороне сервера для JS является node.js. Это очень похоже на Tornado и Twisted (на которые он был вдохновлен). Тем не менее, ему все еще не хватает полноценного фреймворка, похожего на Django или RoR, построенного поверх него.

Scala

Будучи функциональным языком, он отлично подходит для массовых параллельных вычислений, поскольку для веб-программирования общего назначения существует Lift - веб-среда, вдохновленная RoR, используемая, например, FourSquare.

В моем последнем веб-проекте я начал с PHP, потому что раньше использовал его для веб-проекта (быстрый старт), но у меня было много проблем с языком, например, плохая поддержка UTF-8 и динамическая типизация. У меня также есть некоторый опыт работы с Java, и мне действительно нравятся статическая типизация и хорошие инструменты рефакторинга. Java также имеет хорошую производительность по сравнению с PHP. Но мне также нравится выразительность функционального программирования.

Scala и Play Framework

Имея вышеупомянутый опыт, мне очень нравится язык программирования Scala, он статически типизирован, имеет поддержку как объектно-ориентированного, так и функционального программирования и обладает хорошей производительностью по сравнению с другими языками, используемыми для веб-разработки. Но мне не понравились веб-фреймворки для Java и сервлетов, и я обнаружил Play Framework , который поддерживает Scala и Java и имеет очень быстрый цикл разработки - сохраните файл и обновите свою веб-страницу. Я был очень доволен Scala & Play Framework в прошлом месяце. Но поддержка Scala в Play Framework пока не очень развита, как и поддержка инструментов.

Короче говоря, я рекомендую Scala в качестве языка программирования и Play Framework в качестве веб-фреймворка.

На самом деле, вы, вероятно, смотрите на три типа ресурсов:

• Тот, который объясняет основы языка и почему вы хотите его использовать,
• Тот, который сравнивает несколько языков.
• Тот, который критикует какой-то аспект языка.

Оба этих ресурса будут предвзятыми.

• Когда вы объясняете что-то о языке, вы в большинстве случаев пытаетесь убедить читателя использовать его. Так что вы бы редко говорили, что язык отстой.
• Когда вы сравниваете несколько языков, вы всегда предпочитаете один из них.
• Когда вы критикуете что-то, ну, вряд ли можно быть нейтральным.

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

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

Это означает, что вам нужно потратить время (месяцы или даже годы) на занятия. Или вы можете много читать. Но попробуйте прочитать противоречивые вещи . Если кто-то пишет, что он ненавидит PHP, а PHP - один из худших языков, особенно по сравнению с реальными языками, такими как Ruby, C # или Java, попробуйте найти человека, который скажет, что PHP замечательный, и его гораздо проще использовать, чем C #, намного быстрее, чем Java, и намного ... (я действительно не знаю, что), чем Ruby.

Помните одну вещь: если вы уже хорошо знаете язык, вы будете очень критичны в начале, когда будете изучать другой , полагая, что язык, который вы уже знаете, лучше и намного проще в использовании. Это как пользователи Linux, которые ненавидят Windows, и пользователи Windows, которые ненавидят Linux: на самом деле, ни одна ОС не лучше; просто пользователь Linux не знает, как использовать Windows, и наоборот. Только после того, как вы приобретете достаточно опыта, вы сможете правильно решить, какой из них лучше для вас.

Последнее, о чем часто забывают: также очень важно уметь оценивать «окружение» языка:

• Насколько хорош фреймворк (или наиболее часто используемые фреймворки)?
• Легко ли найти хостинг? Вы цените IDE?
• Много ли хорошо написанных сторонних библиотек?
• Состоит ли сообщество высокопрофессиональных разработчиков или, в основном, новичков, которые ничего не знают ни о программировании в целом, ни о самом языке?
• Достаточно ли подробна документация, легко ли ее искать и понимать?
• Часто ли обновляются язык и рамки?
• и т.п.

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

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

Что касается языков, имеющих конкретные цели, у многих языков их нет. Большинство перечисленных вами языков довольно общего назначения. Например, язык Ruby является довольно универсальным языком, подходящим для многих задач. Как только вы добавляете к нему фреймворк, такой как Rails , он имеет довольно конкретную цель.

Это не совсем то, о чем вы просили, но если бы я искал что-то, чтобы вытащить меня из профессиональной колеи веб-разработки, продолжая использовать этот опыт и контакты, я бы занялся написанием приложений для Android и iPhone. Возможность продавать приложение, которое дополняет веб-сайт клиента, может действительно выделить вас в разработке для Интернета, доступ к которому все чаще осуществляется через мобильные устройства.

Вы действительно достигли предела PHP или просто предела PHP, как вы его знаете?

Вы смотрели в Drupal ? Это основанная на PHP CMS и среда программирования, которая настоятельно рекомендует хорошие стандарты и практики кодирования. (Мне приходилось работать с OSCommerce на предыдущих работах, я чувствую вашу боль там.) Хотя он основан на PHP, он настолько отличается, что зачастую «правильный» способ сделать что-то на чистом PHP не является правильным способом сделать это в Drupal, и у вас будет хорошая кривая обучения, чтобы подняться, чтобы действительно овладеть ею. Тем не менее, это может изменить ваши взгляды на возможности PHP как языка и веб-разработки в целом.