Куда идти после php? Ruby или Python?

Question

[Александр]

Собственно вопрос в заголовке :) Хочется услышать принципиальные различия между языками. Для каких задач что лучше подходит?

Answer 1

[Christmas]

Python гораздо быстрее, лучше документация, более отполирован (в руби до сих пор можно увидеть библиотеку генерации html 3.2 — наглядный пример того, что они с трудом управляются с этими десятками тысяч файлов). Твиттер, который часто показывают как пример популярного сайта на рельсах, переписал самую нагруженную часть на Scala, потому как руби сам там не справляется.
Популярность Ruby тесно связана с популярностью рельс. Когда я узнал об этом языке (2001, рельс еще не было) он особо ни кому не был нужен вне Японии. Появились рельсы — Руби стал ультра-модным языком (некоторые до сих пор не могут понять, что Руби и Рельсы — это не одно и то же). Хотя сейчас, кажется, популярность спадает.
Питон же все это время планомерно развивался и популяризировался более-менее самостоятельно.

Потому я бы склонялся к Питону. Сильная сторона руби — ОО и синтаксис.

А вообще это все жутко субъективное мнение, учите то, что больше нравится.

Comments

[kronos]

Уже не гораздо быстрее: есть 1.9.2, jruby и rubinius: где то быстрей питон, где то руби, в целом боевая ничья.

Answer 2

[kmike]

Учите питон.

Он сделает Вас более хорошим программистом, т.к. python

a) не приветствует трюкачество
b) учит принимать самые простые (KISS) решения, не усложнять ничего

образовательный аспект в python очень явно выражен — всегда есть 1 правильный способ сделать что-то. Очень полезная «промывка мозгов» получается, не встречал такого ни в одном другом языке. Учишься смотреть на код «свысока», думаешь больше о том, как его организовать, а не как его написать. После питона на других языках начинаешь писать лучше, т.к. в голове остаются полезные идеи и принципы.

Ruby несколько «мощнее» как язык, дает больше свободы, позволяет делать больше разных трюков и не имеет такой выраженной идеологии. Мне кажется, что выучить ruby тоже полезно и практично, это хороший язык, но python учить полезнее из-за того, что он учит правильным вещам (например, избегать трюков всеми силами).

Еще вариант — выучить javascript. Именно хорошо выучить, чтобы понимать все ФП-фишки языка и его нестандартную объектную модель. Гуру js мало, толпы умеют сделать свистелку на jQuery и не более того. С хорошим знанием js можно довольно просто писать всякие супер-быстрые асинхронные realtime-штуки на node.js. По «мощности» язык вполне адекватен Ruby и Python'у, разве что имеет несколько менее приятный синтаксис и меньше библиотек для серверной части.

Библиотек и для python, и для ruby полно. Imho их больше, чем для php, и способы распространения у них лучше. В питоне есть стандартная библиотека на все случаи жизни с кучей полезностей. Коммьюнити очень разное — в ruby-коммьюнити вы увидите красивые сайты, рекламирующие те или иные библиотеки, кучу эпитетов awesome, каждый второй будет rock-star-programmer и тд, в python-коммьюнити вы увидите, скорее всего, скучноватых суровых инженеров. Я, понятное дело, преувеличиваю)

Области применения у языков похожие, скорость похожая, возможности похожие. Основной критерий тут — нравится/не нравится.

Comments

[Александр]

благодарю за js, совсем забыл про него) полезная штука, да)

[Uznick]

Если что, на питоне есть twisted, как раз для асинхронных риал-тайм штук :)

[kmike]

да, и tornado есть, но
а) v8 в несколько раз быстрее любого интерпретатора python
б) все библиотеки для node написаны в асинхронном стиле. В python вся стандартная библиотека и большинство сторонних написаны в синхронном стиле. Для js просто не было наследия синхронных библиотек, там начали все с 0. В python это частично можно решить какими-нибудь хаками вроде манки-патчинга сокетов, но в node это все очень естественно — просто берешь и используешь все, все асинхронное;
в) лямбды и замыкания в js мощнее, чем в python, это помогает писать в асинхронном стиле более простой код

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

[Zitrix]

лямбды в js мощнее?
с питоном знаком поверхностно, нагуглил:
[x for x in [2, 18, 9, 22, 17, 24, 8, 12, 27] if x % 3 == 0]

что в переводе на js:
[2, 18, 9, 22, 17, 24, 8, 12, 27].filter(function(x) 0==x%3)

а если говорить о v8, то он про сокращенку функции ничего не знает, и надо return писать:
[2, 18, 9, 22, 17, 24, 8, 12, 27].filter(function(x) { return 0==x%3 })

при этом в питоне есть и более привычное ключевое слово lambda — но его даже использовать необязательно, в отличие от js'ных function и return

[kmike]

list comprehensions — очень удобные штуки, и они действительно убирают необходимость в filter и map в питоне, и в большой части лямбд (кстати, в js 1.7 они тоже есть, и когда-нибудь v8 это реализует). Но их никак нельзя использовать для коллбэков, что нас как раз и интересует при написании асинхронного кода. В питоне лямбда — это оператор, возвращающий какое-то значение, в js можно объявлять многострочные лямбды, делающие что угодно. В принципе, это тоже только синтаксический сахар, но удобно. А еще в js мощнее замыкания — внутренняя функция может менять захваченные переменные, в отличие от питона.

Ограничения в питоне — хорошие и логичные, они imho делают написание обычного кода проще и понятнее (никто не будет выпендриваться с функциональными фишками без необходимости, а воспользуется list comprehension или объявит коллбэк явно, отдельной функцией с именем, вместо того, чтоб создавать функцию прямо при передаче ее в параметры другой функции), но это все усложняет написание кода асинхронного. Не то чтобы кардинально усложняет, но все же.

[Zitrix]

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

[1,2,3].forEach(function(val) { 
  myDB.asyncInsert(val, function callback(er) {
    if (er) sys.output(val +" is don't insert because "+ er);
  } ) 
} )

и, если myDB.asyncInsert асинхронный, то почему на питоне аналогичной лямбде с аналогичным асинхронным myDB.insert «никак нельзя использовать для коллбэков»? не знаю, как в питоне с замыканиями, но вместе с er можно и val передавать — в контексте примера.

[Zitrix]

ps я в целом не пытаюсь утверждать, что жс хуже питона (особенно учитывая, что жс мне ближе и много понятнее). мне просто интересно: а вдруг лямбды в жс действительно круче питоновских — с примером.

[kmike]

Лямбда — это анонимная функция. Т.е. функция, которая объявлена без имени. Она не обязательно должна применяться к каким-то там элементам множества, это просто функция без имени. В питоне такие функции можно объявлять только очень простыми, например

lambda x: x*2

В них не может быть ни циклов, ни каких-то операторов, только выражение. Это сознательное ограничение.
Лямбды используются для разной мелочи (указать направление сортировки, передать некий getter, который будет выдавать нужное поле объекта по самому объекту, например). Все более сложное объявляется явно через def. В js на лямбды таких ограничений нет. В обычных программах питоний подход работает отлично, т.к. он провоцирует на правильные действия — выделять сложные куски кода в отдельные элементы. В асинхронных это становится менее удобно (хотя тоже вполне неплохо).

Вот что я имею в виду:

// пример из мануала к node.js
var net = require('net');

net.createServer(function (socket) {
    socket.setEncoding("utf8");
    socket.write("Echo server\r\n");

    socket.on("data", function (data) {
        socket.write(data);
    });

    socket.on("end", function () {
        socket.end();
    });
}).listen(8124, "127.0.0.1");

vs

# гипотетическое переложение предыдущего примера на python
import net

def server(socket):
    socket.set_encoding("utf8")
    socket.write("Echo server\r\n")
     
    # мы не можем создавать обработчики прямо в параметрах add_callback, как было в js
    def on_data(data):
        socket.write(data)

    def on_end():
        socket.end()

    socket.add_callback("data", on_data)
    socket.add_callback("end", on_end)

net.create_server(server).listen(8124, "127.0.0.1");

тут net.create_server и socket.add_callback вполне можно было бы декораторами сделать, впрочем, и писать

@socket.callback("data")
def on_data(data)
    socket.write(data)

но это не отменяет того факта, что лямбды в js мощнее (как и того факта, что в python синтаксис, вобщем-то, приятнее и лаконичнее).

[Zitrix]

понял Вашу точку зрения, спасибо за ответ

Answer 3

[kirill3333]

Java :)

Comments

[LIAL]

Тему читать умеем?

[kirill3333]

Умеем — и Java в этом ряду явно не лишняя. Переход с php на Java очень распространен — все зависит от цели перехода.

[Владимир Чернышев]

Руби ещё можно назвать экзотикой (хотя и он входит в топ10 языков по версии tiobe.com), но питон?! Он скоро php перегонит и по личному опыту переход именно на него с php наиболее прост, несмотря на схожесть синтаксиса php и java/c++/c# — отучиться использовать скобки и $ проще, чем объявлять тип переменных :). И в чём логичность выбора между двумя технологиями (одна из которых, афаик, некроссплатформенна) при выборе языка? Тем более, что под .net и на python писать можно, и под jsp, наверное, тоже ;)

[Christmas]

одна из которых, афаик, некроссплатформенна

Не совсем. mono-project.com

[Владимир Чернышев]

Но и не совсем и даже не односторонне, для кроссплатформенности нужно использовать общее подмножество — писать под mono и думать " а вдруг этой фишки нет в .net" и наоборот. И это не касаясь ещё различий в разных ОС и т. п., то есть даже под Windows может что-то не заработать в .net окружении, что работало в mono под ней же.

[Christmas]

Конечно не односторонне, но тем не менее.
У C#/CLI есть одно хорошее преимущество — они стандартизированы, при чем ISO. Моно, если я не ошибаюсь, реализует стандарт в полном объеме, плюс некоторые нестандартизированные добавки вроде asp.net. Так что если не залазить в дебри windows-реализации, делать кросплатформенные приложения должно быть не и сложно.

[Christmas]

* не сложно

Answer 4

[Narada]

Я бы сначала попробовал Python, недельки 2-3(для общего развития), а потом уже шел в сторону Ruby.

Если бы наоборот — мне было бы дико лень учить Python после познания красоты Ruby :-[

Comments

[Алесь Гузик]

у меня когда-то так и получилось. мне стало лень учить Python потому что руби был слишком красив.
а еще я до сих пор так и не смог понять зачем в Python в каждом методе класса первым аргументом всегда нужно писать self.

[Владимир Чернышев]

В методе класса его писать как раз не нужно, там пишут cls. Self пишут в методе объекта, в статических методах вообще ничего не надо. Хотя это всё не более чем соглашения, может ставить первым параметром, например, this и там, и там если так привычнее.

[miros]

То что self задаётся аргументом явно — это как раз вполне логично. В питоне в отличие от руби любой метод в классе — это изначально полноправный объект. Теоретически вы можете создать простую функцию, использовать её, а потом присвоив атрибуту класса, сделать её тем самым его методом. Чтобы такая функция могла получить доступ к экземпляру класса, он её должен быть как то передан, и поэтому экземпляр как первый атрибут это логично.

[kronos]

В Руби метод тоже объект.

[Антон Дьячук]

В руби все объект :)

Answer 5

[bsboris]

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

Лично я предпочитаю Руби, за «правильную» объектную модель, за читаемый синтаксис, за блоки, за открытые классы. Опять же, еще один громадный плюс Руби — Rails.

Так что ответ стандартный — попробуй оба и учи тот, который ляжет на душу=)

Comments

[charon]

то есть у Питона синтаксис хуже читается, чем у Руби?

[Uznick]

> за читаемый синтаксис
… чо?

Answer 6

[avatarmov]

Ruby определённо.

Меня Python убил своим синтаксисом и полной непохожестью на другие языки.

Comments

[Владимир Чернышев]

Да ладно, что там такого полностью непохожего на другие языки? Инфиксная форма записи выражения (не префиксная, как в Лиспе, или постфиксная, как в Форте), реализованы все основные алгоритмические и ООП конструкции, причём такими же словами, что и в большинстве других языков: ветвление — это if, цикл — while и for, класс — это class и т. д. Что ещё? А, логика зависит от отступов? :) Зато никаких холиваров на тему как располагать скобки: Р И более компактный код по сравнению со многими такими способами

[avatarmov]

В питоне во множестве случаев приходится писать десяти-строчный код, который в руби является одной строчкой.

[mukizu]

Во множестве случаев «прочитать» 10 строчный код куда проще и быстрее, чем одну строку

[avatarmov]

Это кто вам сказал? Я не имею ввиду случае, где в одной строке куча скобок, какого нибудь мусора и т.д., я имею ввиду конкретно: в python'е сложный код, в Ruby есть функция, которая делает примерно тоже самое.

[djakomo]

а можно пример? действительно интересно.

[avatarmov]

Хорошо. Есть неплохой сайт, где можно сравнить языки по времени выполнения программы, кол-ву использования памяти и кол-ву коду — shootout.alioth.debian.org/
Вот сравнение Ruby:Python — shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=yarv&lang2=python3

А вот одна из программ, написанная на питоне, взятая с того же сайта:

import sys
import multiprocessing as mp


def make_tree(i, d):

    if d:
        d -= 1
        return (i, make_tree(i, d), make_tree(i + 1, d))
    return (i, None, None)


def check_tree(node):

    i, l, r = node
    if l is None:
        return i
    else:
        return i + check_tree(l) - check_tree®


def make_check(itde, make=make_tree, check=check_tree):

    i, d = itde
    return check(make(i, d))


def get_argchunks(i, d, chunksize=5000):

    assert chunksize % 2 == 0
    chunk = []
    for k in range(1, i + 1):
        chunk.extend([(k, d), (-k, d)])
        if len(chunk) == chunksize:
            yield chunk
            chunk = []
    if len(chunk) > 0:
        yield chunk


def main(n, min_depth=4):

    max_depth = max(min_depth + 2, n)
    stretch_depth = max_depth + 1
    if mp.cpu_count() > 1:
        pool = mp.Pool()
        chunkmap = pool.map
    else:
        chunkmap = map

    print('stretch tree of depth {}\t check: {}'.format(
          stretch_depth, make_check((0, stretch_depth))))

    mmd = max_depth + min_depth
    for d in range(min_depth, stretch_depth, 2):
        i = 2 ** (mmd - d)
        cs = sum((sum(chunkmap(make_check, argchunk))
                  for argchunk in get_argchunks(i, d)))
        print('{}\t trees of depth {}\t check: {}'.format(i * 2, d, cs))

    print('long lived tree of depth {}\t check: {}'.format(
          max_depth, make_check((0, max_depth))))


if __name__ == '__main__':
    main(int(sys.argv[1]))

И на руби:

def item_check(left, item, right)
  return item if left.nil?
  item + item_check(*left) - item_check(*right)
end

def bottom_up_tree(item, depth)
  return [nil, item, nil] unless depth > 0
  item_item = 2 * item
  depth -= 1
  [bottom_up_tree(item_item - 1, depth), item, bottom_up_tree(item_item, depth)]
end

max_depth = ARGV[0].to_i
min_depth = 4

max_depth = min_depth + 2 if min_depth + 2 > max_depth

stretch_depth = max_depth + 1
stretch_tree = bottom_up_tree(0, stretch_depth)

puts "stretch tree of depth #{stretch_depth}\t check: #{item_check(*stretch_tree)}"
stretch_tree = nil

long_lived_tree = bottom_up_tree(0, max_depth)

min_depth.step(max_depth + 1, 2) do |depth|
  iterations = 2**(max_depth - depth + min_depth)

  check = 0

  for i in 1..iterations
    temp_tree = bottom_up_tree(i, depth)
    check += item_check(*temp_tree)

    temp_tree = bottom_up_tree(-i, depth)
    check += item_check(*temp_tree)
  end

  puts "#{iterations * 2}\t trees of depth #{depth}\t check: #{check}"
end

puts "long lived tree of depth #{max_depth}\t check: #{item_check(*long_lived_tree)}"

Чувствуете разницу в количестве кода?

[kmike]

А вы не почувствовали, что алгоритмы-то разные реализованы? Что в версии на python на обработку запускается количество процессов по числу ядер процессора? И что под это дело алгоритм переписан-распараллелен? Чтобы выжать побольше скорости на таких счетных задачах в отсутствие JIT? Что это синтетический код и так почти никогда не пишут? Нет, не почувствовали?

На картинку сегодня наткнулся по этому поводу: i.imgur.com/G7WyP.gif — хорошо иллюстрирует этот топик, где фанаты haskell ругают все нефункциональные языки, фанаты ruby ругают питон, а фанаты питона вроде меня ругают php.

Бр, повелся на троллинг.

[djakomo]

avatarmov, я не программер ни питона, ни руби — поэтому такими алгоритмами меня не запугать :)
Вы говорили: «В питоне во множестве случаев приходится писать десяти-строчный код, который в руби является одной строчкой». Вот эти строчки я бы и хотел увидеть :)

[avatarmov]

Я имел ввиду, что код в руби короче получается. Вот доказательство — shootout.alioth.debian.org/u64/benchmark.php?test=all〈=yarv&lang2=python3

[djakomo]

1. тот код который вы привели — не идентичен, об этом написал kmike.
2. В тестах которые вы привели, сравниваются показатели производительности языков, а никак не количество строк кода.

[avatarmov]

1. Это может быть, тут мне действительно трудно спорить.
2. Хм, присмотритесь к таблице. Первая группа столбцов отвечает за производительность, вторая — за количество используемой памяти, третья — за количество кода.

[djakomo]

avatarmov, да, точно. Вот сравнение. Но тут объемы кода примерно на одном уровне. Значительных отклонений нет.

shootout.alioth.debian.org/u32/chartvs.php?r=eNoljsEVRFEEQ1sSBKlC%2F92M92fliNxEdsNmsyIam1NULI1kbWoi%2F9sTnSNuNRl%2Bt3b1Uibh4ZZ9%2BPlPTNLPgqF%2FmQ0ukYWX2VZnMXhoOT5eB7TPnBjVfkVK4EYJ%2BQDiABhKm2%2B9d5X93Ub1HkTMFSm8%2FAfkPS4E&m=eNozMFbwTy5RMDIwNFAoNTZSyAMAJA8EFQ%3D%3D&w=eNqrTCwq8y%2BoLMnIzwMAHDQEtA%3D%3D

[avatarmov]

И всё таки чуть меньше :) Ладно, не будем спорить.

Answer 7

[Арвид Годюк]

Знать PHP != уметь на нём делать сложные вещи правильно.
Вместо изучения другого языка, углубитесь в сам PHP, а так же займитесь очень плотно MySQL (там не паханое поле оптимизаций, приёмов и.т.д) и прочими связанными технологиями: Redis, MongoDB, Sphinx, акселераторы (они умеют не только хранить опкод), повышайте скилл уменя работать с memcache, изучайте архитектуры, изучите какой-нить framework (рекомендую Yii — очень грамотно построен и расширяется на все 100% любой компонент написанием собственно этого самого компонента + запись в конфиге о переопределении стандартного компонента. Никаких костылей и правок самого фреймворка. В общем очень правильный OOP в реалиях PHP).

Comments

[Арвид Годюк]

PHP 5.3 к тому же появился сборщик мусора, можно делать простые демонизированные сервисы. Так же хорошо очень писать консольные приложения. Инструментарий стартовый в интернете есть. Очень удобно. Т.е. в 99% случаев для необходимостей WEB разработки самого PHP хватает. Тот 1% как правило оперирует уже другими объёмами и там уже есть люди, которые являются спецами в своей области и они сами напишут то, что нужно. А вы будете спокойно делать свою работу и будете вместе интегрировать свои приложения.

[kmike]

Ну вот научится, предположим, человек делать сложные вещи на php правильно. И так и не узнает, что сложными эти вещи являются только в php. Расширяйте кругозор, это точно стоит того. PHP как язык и как платформа для программирования гораздо хуже и python, и ruby.

Я, конечно, понимаю, что это может быть воспринято как понты, но все же. Буквально недавно была возможность сравнить (совершенно ненаучно, но очень явно). 2 команды делали одинаковый продукт (совершенно одинаковый), мы и еще одна. Мы писали на django и нас было 4 человека (из них я — единственный программист), они — на php и их было 15 человек (8 что-ли программистов). И при этом время разработки фич у нас оказывалось меньше, проработка деталей больше. Они постоянно не укладывались в сроки и выкатывали сырые продукты. Многое из того, что у нас сделано, той команде еще делать и делать. Фича, которая делалась у нас за 3-5 дней, ими была оценена в месяц (и до сих пор не реализована).

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

Вы пишете про сложность и правильный ООП. В том-то и суть, что на других платформах те же задачи решаются без сложностей, с ней не нужно бороться, и, кстати, даже тяжелая артиллерия ООП (которая, к слову, в ruby-python уж поправильней, чем в php) не всегда нужна. «Скилл работы с memcached» — чего там изучать-то, висит словарь в памяти, что может быть проще. Ясное дело, «silver bullet» не существует, и python — не silver bullet, а просто хороший инструмент со своими достоинствами и недостатками. Python и Ruby — давно мейнстрим, а не экзотика, фреймворки под них (да те же django и rails) — более матерые, проработанные и удобные, чем любой фреймворк на php. У php тоже есть технические плюсы, но они являются плюсами только на очень-очень простых проектах.

[Владимир Чернышев]

2kmike:
А команда на php писала свой продукт с использованием фреймворка или всё с нуля? Просто фраза «мы — на django, они на php» как-то некорректно смотрится. Не могу представить, что какую-то фичу на симфони (а там многое заимствовано и с джанго, и с рельс) делать на порядок(!!!) дольше, чем на джанго, кроме, может быть, каких-то очень специфичных, которые решили включить в код джанго, какая-нибудь авторизация через LDAP например.

Сам какого-то особого удобства у джанго не заметил, и при желании, имхо, можно написать практичеcки такой же фреймворк и на php, и чуть ли не построчно можно переписывать (если позволит синтаксис построчно, иначе, конечно, нужны будут костыли, но большинство их останутся, по-моему, внутри фреймворка) — python и php всё же схожи куда больше, чем, например lisp и php. Хотя, может быть, не понял удобства django, потому что практически не пользуюсь фичами python, такими как генераторы, например — пишу, в основном, не пользуясь «ситаксическим сахаром» и в итоге, наверное, мой код легко перенести на любой императивный язык с динамической (а то и статической) типизацией, где есть if, for, while и class :)

[kmike]

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

Построчно переписать django не выйдет именно из-за различий в возможностях языков, как не вышло ни у кого рельсы переписать по-нормальному на php. Костыли будут торчать из всех щелей, начиная с отсутствия стандартной библиотеки. Будет также мешать отсутствие метаклассов и разных ФП-фич.

Хотя сейчас в php начали вроде элементы ФП вводить, это должно фреймворкам помочь.

Я, признаюсь, на php и php-фреймворки года 2 не смотрел детально, но статьи вроде той, что сейчас висит на главной (про тестирование контроллеров в symfony) реально пугают — какие-то жуткие xml-файлы и «Если ваши контроллеры реализуют интерфейс ContainerAware, вы получите DIC (dependency injection container) внедренный через метод ContainerAware::setContainer(), который вы можете использовать для доступа к любому сервису, который вы объявили в DIC». Это никак не назовешь стремлением к простоте, это подходы из java, а не стремление к быстрой разработке. В Java эти подходы используются для борьбы со сложностью проектов, причем большАя часть этой сложности обусловлена именно языком и его ограничениями, и то, что в php тащат эти подходы, немного настораживает (неужели там те же проблемы?).

[Арвид Годюк]

То что с Java тащят, это да, плохо.
Но, ИМХО, что Simphony, что Zend Framework — у них ноги растут от корпоративных приложений и они слишком монструозны.
Да, PHP другой, такого как в Django вы не получите. Но точно так же вы вряд ли получите Rails из Ruby в Python. Что-то да будет не так. Сравнивать нужно исходя из возможностей самого языка, а не пытаться фреймворк из одного языка приерить на другой язык.
ИМХО, самое элегантное и легковестное сейчас это Yii. Он относительно молодой, но по удобности гораздо лучше всего остального.

[Владимир Чернышев]

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

Насчёт построчно, погорячился, конечно, хотя на php4 писать бы точно не стал, а вот на 5.3 думаю много костылей наружу торчать не будет, хотя руку на отсечение не дам.

XML меня самого испугали, сам пользуюсь обычно куда более простым и компактным (тот роутинг занял бы у меня две строчки, а при желании и одну) YAML (симфони2 из коробки поддерживает минимум 3 вида конфигов, включая простой php-код, которым тоже частенько пользуюсь, когда не вижу смысла выносить что-то в текстовый конфиг). А формально в исходниках примеров ни слова про интерфейсы и контейнеры, видимо «магия» или утиная типизация (с DIC не разбирался ещё).

Answer 8

[agh]

Я за питон :) для веба django

Comments

[Horse]

Аналогично)

[LIAL]

А обоснование ??? Зачем просто голословности

[avatarmov]

У руби для веба есть Ruby on Rails, что значительно круче django

[Владимир Чернышев]

Хорошее обоснование преимущества языка «круче фреймворк» — для тех, кто тёмные очки носит даже ночью? ;)

Answer 9

[chetzof]

Выучите Гугл ;) stackoverflow.com/questions/673964/should-i-learn-ruby-or-python

Answer 10

[mukizu]

Думаю наиболее оптимальный вариант — начать изучать и то и другое. А дальше смотреть на то что ближе, удобнее, понятнее etc. именно вам. Ну и на востребованность на рынке.

Answer 11

[aeryaguzov]

ИМХО, если хорошо знаешь серверные технологии, развивайся в сторону клиентских технологий! Так что как выше уже советовали — javascript!

Comments

[Сергей]

Я стал понимать основную фишку яваскрипта после того как изучил питон только)

Answer 12

[try4tune]

Разработчик программирует не на языке, а с помощью языка. Советую больше развивать свои знания в сторону архитектуры ПО. Перейти на почти любой другой язык для грамотного разработчика особого труда не составит.

Comments

[Павло Пономаренко]

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

[try4tune]

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

[andoriyu]

вы видемо пишите на^W с помощью хаскеля.

[So1]

Угу. Вы с помощью английского языка разговаривать умеете?

Answer 13

[Евгений]

А какую цель приследуете? Просто для галочки, я знаю вот стока-то языков для одного и того же?

Comments

[Александр]

разные языки — разные возможности

[Yan169]

С точки зрения профессионального развития, я бы посоветовал попробовать отличные от web-разработки задачи, например desktop soft или mobile apps. Чем дальше будет сфера задач от веба, тем лучше для кругозора и профессионального опыта. А исходя из выбранной задачи уже и подбирать язык.
Вариант «Я умею программировать на C++ для desktop, писать мобильные приложения на Java и создавать сайты на PHP» на мой взгляд предпочтительнее, чем «Я могу написать сайт на Python, Ruby или PHP».

[Masterkey]

как альтернативу тому, что сказано выше, можно взяться за питон со стороны PyQT для десктопа, но плюсы всеравно кошернее

[Christmas]

Человек, знающий плюсы, питон со всеми рюшиками освоит за месяц.

[kmike]

Знать язык != уметь на нем программировать. Программировать на python хороший программист на C++ научится правильно научится через полгода-год, когда выкинет всю C++-ную ерунду из головы. Сужу по себе ;)

Answer 14

[professor_kuvalda]

Учи python. Ведь он используется не только в веб-программировании, а и в куче других вещей:
— www.amazon.com/Natural-Language-Processing-Python-Steven/dp/0596516495
— www.sagemath.org/
— code.google.com/p/sympy/
— twistedmatrix.com/trac/
— и многое другое

Comments

[Владимир Чернышев]

Да даже если открыть список процессов на многих машинах с Linux, то наверняка найдётся что-то на python

[andoriyu]

все дело в том, что когда это писалось ruby был ооочень медленный и комментарии в коде были на японском, а на память там вообще МПХ положили.
p.s.
twisted это пиздец и сравнивать его с божественной EventMachine не надо :D

[professor_kuvalda]

> все дело в том…

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

> twisted это пиздец и сравнивать его с божественной EventMachine не надо

тоже как-то пофигу — неосилившие твистед его постоянно ругают

Answer 15

[StrangeAttractor]

Я тоже задавался таким вопросом — Ruby или Python… В результате выбрал Scala и доволен как слон…

Answer 16

[PingMe]

C++ :)

Answer 17

[Volfram]

Сказано много и хорошо, добавлю лишь свои 5 копеек:
Python лучше для изучения, если хочется постепенно выходить за рамки Web. Да и его навязывание дисциплины кода лишним не будет.

Answer 18

[Avant]

Ruby.
Плюсы:
Ruby on Rails
Отличное сообщество
ООП, синтаксис
Много материала, правда большинство на английском(книги, блоги, скринкасты)
RubyGems

Answer 19

[Алексей Сидоров]

Ruby и Python хоть и имеют красивую, правильную объектную модель, но очень далеки от того, как работает реальное железо. В итоге это выливается в чудовищный оверхед, причем Ruby умудряется тормозить сильнее Python'а, php в этих же тестах где-то рядом, но все они плетутся в хвосте.
Я бы порекомендовал поизучать языки программирования со статической типизацией: они принципиально быстрее и ближе к железу.

Comments

[Владимир Чернышев]

>они принципиально быстрее и ближе к железу.

Ассемблер ещё быстрее и ближе ;) Вопрос в том компенсируется ли оверхед в ресурсах и производительности приложения оверхедом в скорости разработки и удобстве поддержки.

[MikhailEdoshin]

Не знаю, я периодически лазаю в исходники Python — все у него там нормально с тем, как работает реальное железо :) Overhead, конечно, есть, кто бы спорил, но зато пишется исключительно быстро. Я как бы имею возможность сравнить — мне пришлось часть кода перенести из Python на C (не из-за оверхеда) — так перенос уже написанного кода занял в разы больше, чем его написание.

[Алексей Сидоров]

Не скажу, что разработка на компилируемом D сильно дольше, чем на Python и Ruby, да и на той же Java и C# проги весьма быстро делаются. Да они даже на С++ быстро пишутся если уметь.

[kmike]

Ну и зря не скажете. Т.к. на самом деле сильно быстрее и проще. Половина design patterns — это костыли для обхода ограничений языков вроде java или C++. Вместо того, чтобы использовать простую языковую конструкцию python или ruby, там нужно создавать дополнительный слой абстракции, писать какие-то классы, что неминуемо приводит к усложнению проекта и к замедлению его разработки. Чем больше кода, чем выше сложность проекта, тем медленнее его развивитие и тем сложнее его поддержка. А на языках вроде java кода *значительно* больше, и абстракций там вводить нужно *значительно* больше, чтоб проект мог развиваться.

[Алексей Сидоров]

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

[kmike]

Да, согласен, плохо не станет. Сам много лет писал на компилируемых языках. В школе pascal, в институте C/C++, на первой работе программировал 3d графику (C++/OpenGL), на второй — реализовывал (на C++) различные алгоритмы сжатия изображений через вейвлет-преобразования. Софт для связи какого-то дефектоскопа с PC писал еще. Суммарно более 10 лет получается опыта программирования на компилируемых языках, до того как в веб ушел. Но просто вопрос в теме, как мне показалось, явно подразумевает выбор динамического языка для быстрой разработки, вероятно, под веб. C++/D и тд тут не в тему, т.к. скорости работы python/ruby в большинстве случаев хватает за глаза, а время разработки на них в разы меньше. Области применения разные. И вообще ни из чего не следует, что автор топика C++ не знает.

Answer 20

[Stepuk]

Python — это идеологический наследник PHP'а. Такой же бестолковый язык, за которым, ко всему прочему, не видно никакой идеи. Просто неуклюжая комбинация стыренных отовсюду концепций. Ничего нового. Python не нужен.

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

Вывод? Выучите Haskell, пора посмотреть на программирование под другим углом.

Comments

[Christmas]

>> Python — это идеологический наследник PHP'а
Дальше можно не читать.

[Narada]

Где вы такую траву берёте?

[Александр]

Троллите вы конечно знатно, но если я захожу выучить что-то десктопное кроме С++, я лучше выучу java

[andoriyu]

передай пацанам, что обновили инфу для троллинга :D инфа по руби не актуальна же.

[So1]

Не существует плохих или хороших языков программирования. Существуют языки программирования, предназначенные для решения конкретных задач. (с) забыл автора слов :(

Я выбрал Python. Для веба, например, сравнивая Django и RoR, первый в несколько раз быстрей и кушает меньше памяти. На питоне написано достаточно много модулей для Linux, то есть, его полезно знать так же как и bash, например. А еще код на питоне не может выглядеть плохо так как форматирование — фича самого языка а не программиста. И сколько программисты бы не утверждали, что они всегда супер-правильно форматируют код, свои слова подтверждают еденицы. Порой смотришь на хитросплетения оргомного количества вложенных циклов и для начала форматируешь код за тех нерадивых программеров, а потом уже и приступаешь к работе. Я бы еще и javadoc'и заставлял писать к функциям на уровне языка :)

[VlK]

И чего парню с того Хаскелла будет? Побалуется, повыворачивает мозги с монадами, прочей требухой. Может, тогда уж Лисп? Тогда толково будет функциональщину использовать в тех же Питонах и Руби.

[usr]

«Python — это идеологический наследник PHP'а.»
«Ruby — это идеологический наследник Perl'а.»

Наркоман что ли?

Answer 21

[stranniknavsegda]

ПАНАЦЕИ НЕ СУЩЕСТВУЕТ! Каждому пациенту свое! У одних аллергия на Ruby, у других на Python… у N-х на Haskell… попробуйте и то и другое и третье и выбирете что по душе…

Answer 22

[Ogra]

Если у вас появилось желание выучить что-то еще, могу предложить вот что:
Прочитайте статью Эрика Рэймонда «Как стать хакером», и выберите язык из предложенных там — это Perl, Python, C, LISP. Небольшая цитата:

Лучше всего, на самом деле, выучить все четыре этих языка (Python, C/C++, Perl, и LISP). Помимо того, что это самые важные хакерские языки, они демонстрируют очень разные подходы к программированию и каждый из них научит вас ценным вещам.

Comments

[professor_kuvalda]

там уже и java в список входит

Answer 23

[Антон Корзунов]

Учите Lua — ФП аля JS. Почти на 99% схожи эти языки. Ну кроме банального синтаксиса.
Или про него все забыли?

Answer 24

[Di Lee]

А в чем то такая необходимость переходить на другой язык?
ПХП надоел или не устраивает чем то?
Вообще на ПХП такие вещи можно вытворять, если знать и применять еще смежные технологии… А там поверьте — есть куда развиваться… :)

Comments

[Александр]

хочется чего-то другого, хотя бы на время)

Answer 25

[NickMitin]

И то и другое, зачем выбирать?

Answer 26

[HeBonpoc]

Зачем "после PHP" куда-то идти? Он развивается - развивайтесь вместе с ним без понижения ЗП :) А в свободное время возьмите реальную задачку из ваших проектов и реализуйте на ruby и на python, тогда и оцените. При постановке вопроса ruby vs python получается глупый холивар