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

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

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

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

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

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

лямбды в 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

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

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

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

[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 передавать — в контексте примера.

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

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

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 синтаксис, вобщем-то, приятнее и лаконичнее).

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

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

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

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

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

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

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

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

* не сложно

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

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

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

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

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

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

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

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

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

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

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

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

Хорошо. Есть неплохой сайт, где можно сравнить языки по времени выполнения программы, кол-ву использования памяти и кол-ву коду — 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)}"

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

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

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

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

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

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

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

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

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

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

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

Ну вот научится, предположим, человек делать сложные вещи на 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 :)

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

Построчно переписать 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 не разбирался ещё).

Аналогично)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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