LINUX.ORG.RU

Ответ на: комментарий от olelookoe

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

HTML/CSS тоже не описывают UI, это средства разметки текста. То, что там есть полтора виджета стандартных, вовсе не делает это говно пригодным для UI. По факту получается тот же зоопарк, что и с гуи-тулкитами, только гораздо хуже в плане реализации. В общем, удачи делать хоть сколько-нибудь сложный UI на голом html с ванильным js.

anonymous ()
Ответ на: комментарий от anonymous

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

Все гораздо хуже, потому что электрон это не обычный тулкит, а еще один зоопарк для жснутых. Так что получили зоопарк в зоопарке. Как раз самая жопа с вебней в том, что никаких стандартных (хоть бы и де-факто) решений для UI там нет, только DOM и скриптуха - дальше крутись как хочешь.

anonymous ()
Ответ на: комментарий от Woolf

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

В топике про python и django. То есть создание сайтов автора интересует

Если твой скрипт ждёт ответа от БД - то ты что-то делаешь не так.

То есть? От данных из запроса в БД очень сильно зависит результат работы всего скрипта. Написал какую-то глупость

А если у тебя бэк обладает хреновой архитектурой - то ты что-то делаешь не так.

А что написал?

dicos ()
Ответ на: комментарий от byko3y

я-то думал про компиляцию в маш коды

Зачем компилировать js в машкоды? Браузеры и без этого решето.

Транспилятор js->js (prepack.io) — сырая поделка, не умеющая ничего готового для продакшн.

Другой транспилятор почти-js->js (typescript) — делает код чуть жирнее и чуть медленнее в обмен на удобство разработки.

Третий транспилятор js->js (babel) — тормозная поделка сама по себе, да ещё и делает код, как правило, медленнее.

Транспилятор что-нибудь->js (да хотя бы ocaml) — умеет в статический анализ кода и в оптимизации на основе этого. В конце концов, позволяет record’ы и enum’ы без накладных расходов (а не как тайпскрипт) за счёт не настолько удобного interop’а с прочим жабоскриптом. И всё это работает быстрее, чем babel или typescript-компилятор.

Зачем писать на js?

x3al ★★★★★ ()
Последнее исправление: x3al (всего исправлений: 1)
Ответ на: комментарий от byko3y

WAsm и asm.js исполняются не на жаваскрипте - что не так?

Во-первых, то не так, что эта фраза — шизофазия. А во-вторых эти инструменты и возникли и являются частью именно javascript-мира. При этом ты заявляешь, что js не развивается и устарел. Ну это же ЛОЛ. js не только очень развитая и передовая платформа, а вообще двигатель прогресса. Поэтому я и спрашиваю, каких таких инструментов ты хочешь? Покажи что есть лучше за пределами js и иже с ним?

no-such-file ★★★★★ ()
Ответ на: комментарий от x3al

Зачем компилировать js в машкоды? Браузеры и без этого решето.

Это делают JIT-компиляторы всех быстрых движков JS, получая производительность примерно 1/4 от кода на С с ручным управлением памятью.

Другой транспилятор почти-js->js (typescript) — делает код чуть жирнее и чуть медленнее в обмен на удобство разработки.

Ты не осознаешь, что тайпскрипт умеет статически анализировать жавоскрипт.

Транспилятор что-нибудь->js (да хотя бы ocaml) — умеет в статический анализ кода и в оптимизации на основе этого. В конце концов, позволяет record’ы и enum’ы без накладных расходов (а не как тайпскрипт) за счёт не настолько удобного interop’а с прочим жабоскриптом. И всё это работает быстрее, чем babel или typescript-компилятор

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

Зачем писать на js?

Вот я пишу на JS. Но у меня нет выбора: vue.js адекватно поддерживает только его. Typescript в полукостыльном виде только-только вводят.

byko3y ()
Ответ на: комментарий от no-such-file

А во-вторых эти инструменты и возникли и являются частью именно javascript-мира.

Ты бы еще написал «являются проявлением javascript-любви, javascript-достоинства». А потом еще меня в шизофазии обвиняет. Выдумал себе какой-то javascript-манямирок, и проецирует его на меня.

При этом ты заявляешь, что js не развивается и устарел

Жаваскрипт развивается и устарел. Отсюда массово возникают альтернативные платформы, на которых нельзя исполнить javascript, хоть они очень часто и взаимодействуют тесно с JS, поскольку в текущее время это единственная общепринятая среда выполнения для браузеров. Тот же WebAssembly не может исполнить JavaScript, но для взаимодействия с браузером кода на WAsm используют именно JS. asm.js, хоть и может быть исполнени в обычном движке JS, но смысл обретает только в совершенно ином режиме компиляции AOT на специальном движке, который опять же не поддерживает обычный JavaScript, то есть, это уже не жаваскрипт, а новый язык, который из соображений совместимости сделали синтаксически похожим на JS.

byko3y ()
Ответ на: комментарий от byko3y

Ты бы еще написал

Но я так не написал. К слову о том, кто тут что проецирует на оппонента.

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

Ясно-понятно. Ты на вопрос отвечать собираешься?

no-such-file ★★★★★ ()
Ответ на: комментарий от anonymous

Да, но только я вот прямо сейчас могу взять любую страничку из тырнетов и применить к ней кастомный CSS, и болт класть на то какой там модный очередной UI фреймворк. Потому что стили применяются к DOM, а не к васипупкинскому творению. Удачи проделать то же самое на десктопе. То, как нечто похожее попыталиь запилить гтк и кути - лучше бы и не пытались.

olelookoe ()
Ответ на: комментарий от olelookoe

Да, но только я вот прямо сейчас могу взять любую страничку из тырнетов и применить к ней кастомный CSS, и болт класть на то какой там модный очередной UI фреймворк.

Во первых, не можешь, потому что очередной UI фреймворк твой кастомный цсс затрёт своим цсс-ин-жс. Во вторых, нахуя?

anonymous ()
Ответ на: комментарий от anonymous

Во первых, не можешь

Во-первых могу и делаю это. Например DarkReader, мне так удобно, глаза меньше устают.

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

olelookoe ()
Ответ на: комментарий от rebforce

Молча, блин. В JS оператор доступа к свойству (.) определён для объектов любого типа, а проверка идёт уже по значениям.

Может, то он с проверками типа в TS перепутал?

anonymous ()
Ответ на: комментарий от olelookoe

ней кастомный CSS

Например DarkReader

TypeScript 81.7%. Который зависит от апи, которое перелопачивают каждый месяц крестовые разработчики по желанию левой пятки.

Стандартизированый цсс такой стандартизированый.

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

– Докажи, что так.

– Нет, это ты докажи что не так!

Блаженен верующий, чо.

anonymous ()
Ответ на: комментарий от anonymous

TypeScript 81.7%.

Да пофигу чем там генерится CSS и в зависимости от каких условий. Важно то, что на каждом из стопицотмильонов сайтиков все тот же DOM и все тот же CSS, и это дает возможность настраивать UI прямо здесь и сейчас. Стандартным образом, да.

olelookoe ()
Последнее исправление: olelookoe (всего исправлений: 1)

На Python просто библиотек больше, там все программы состоят в основном из import крутая_библиотека, всё остальное делают сами библиотеки. Никого не беспокоит производительность программы, пока её можно слепить из готовых библиотек за пару минут поиска нужных клавиш для набора названий этих библиотек… Ненавижу питон, он своими библиотеками мешает писать велосипеды, а какой смысл в программировании, если нельзя писать велосипеды?

anonymous ()
Ответ на: комментарий от monk

переход между двумя страницами с подсчётом общего числа переходов.

При попытке запустить этот код:

send-url: Couldn't find a browser to open URL: "http://localhost:39495/servlets/standalone.rkt"

Но, как я понимаю, имелось ввиду что-то вроде:

from flask import Flask, redirect
app = Flask(__name__)

@app.route('/')
def start():
    return redirect('/1/1')

@app.route('/<int:phid>/<int:n>')
def phase(phid, n):
    return f'<html><body><h1>Phase {phid}</h1><a href="/{3-phid}/{n+1}">click me! {n}</a></body></html>'

if __name__ == '__main__':
    app.run()

(define (get-pid pid) ...

И вышло раза в 2 длиннее. Получается, что этот код, пусть и не намного, но всё-таки проще писать на питоне.

Второе — просто вызов библиотечной функции.

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

anonymous ()
Ответ на: комментарий от anonymous

send-url: Couldn’t find a browser to open URL: «http://localhost:39495/servlets/standalone.rkt»

Значит, нету у тебя x-www-browser. Надо в DrRacket в Настройки пользователя/Браузер указать, что у тебя есть. Или просто вручную в любом браузере вбить этот URL.

имелось ввиду что-то вроде:

Да. Но на питоне пришлось явно указывать route.

Кроме того, я могу сделать:

#lang web-server/insta

(define (start request)
  ((phase (open-input-file "/etc/passwd")) request))
 
(define ((phase f) request)
  (define (response-generator embed/url)
    (response/xexpr
     `(html
       (body (h1 "Phase 1")
             (p ,(read-line f))
             (a ((href ,(embed/url (phase f))))
                "next line")))))
  (send/suspend/dispatch response-generator))

Как будешь в маршрут открытый файл передавать?

И вышло раза в 2 длиннее.

По буквам — да. По количеству синтаксических элементов примерно одинаково. Если стремиться к компактности по буквам, то идеал — Perl, а ещё лучше APL. Python в своё время победил Perl, несмотря на то, что почти весь код становился примерно в два раза длиннее.

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

Тогда бы мы до сих пор писали на фортране и коболе, как самых удобных (читай «имеющих нужные библиотеки») языках.

monk ★★★★★ ()
Последнее исправление: monk (всего исправлений: 1)
Ответ на: комментарий от monk

Значит, нету у тебя x-www-browser.

Вроде, есть:

$ x-www-browser --version
Mozilla Firefox 68.2.0esr

Или просто вручную в любом браузере вбить этот URL.

Там не было смысла вбивать урл. Оно не запустилось. Вывело ту ошибку и вышло.

Да. Но на питоне пришлось явно указывать route.

В каком смысле? В ракете он разве не точно так же явно указан?

Как будешь в маршрут открытый файл передавать?

Тут получается, что можно вообще ничего не передавать... Что-то вроде:

from flask import Flask
app = Flask(__name__)

f = open(__file__)

@app.route('/')
def start():
    return f'<html><body><h1>Phase 1</h1><p>{f.readline()}</p><a href="/">next line</a></body></html>'

if __name__ == '__main__':
    app.run()
Хотя я не совсем понимаю исходный вариант... Как оно должно работать?

По буквам — да. По количеству синтаксических элементов примерно одинаково.

Там разница вдвое почти по любым подсчётам: по буквам, по строкам, по синтаксическим элементам. По уровню вложенности вызовов разница чуть ли не на порядок.

Лично мне конструкции вида: f(g(h(a(b()), c()), d(b()))) всегда казались более сложными и тяжёлыми для понимания, чем f.g.h[a.b(), c()] = d.b().

Python в своё время победил Perl, несмотря на то, что почти весь код становился примерно в два раза длиннее.

Разве? Мне казалось, что питон проигрывал перлу только на однострочниках. В обычном же коде перл не особо выигрывал. Зато его код был жутко замусорен спец.символами <@$%>... Это тоже осложняло чтение.

Тогда бы мы до сих пор писали на фортране и коболе, как самых удобных (читай «имеющих нужные библиотеки») языках.

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

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

anonymous ()
Ответ на: комментарий от anonymous

Там не было смысла вбивать урл. Оно не запустилось. Вывело ту ошибку и вышло.

А ты его точно из DrRacket запускал? Если из консоли, то сделай такой текст программы:

#lang racket
(require web-server/servlet web-server/servlet-env)

(define (start request)
  ((phase (open-input-file "/etc/passwd")) request))

(define ((phase f) request)
  (define (response-generator embed/url)
    (response/xexpr
     `(html
       (body (h1 "Phase 1")
             (p ,(read-line f))
             (a ((href ,(embed/url (phase f))))
                "next line")))))
  (send/suspend/dispatch response-generator))

(serve/servlet start)

Тогда он просто www-сервер запустит.

В каком смысле? В ракете он разве не точно так же явно указан?

В ракете (embed/url …) его делает автоматически. Соответственно, я могу передавать в качестве параметра любое замыкание (а в качестве связанных значений произвольные данные: ссылки на файлы, массивы, хэши, результаты запроса из БД, …).

Тут получается, что можно вообще ничего не передавать… Что-то вроде:

У тебя на все сессии один открытый файл. Надо, чтобы в каждой сессии позиция в файле была независима (как в варианте со счётчиком).

Там разница вдвое почти по любым подсчётам: по буквам, по строкам, по синтаксическим элементам. По уровню вложенности вызовов разница чуть ли не на порядок.

Считаем.

Python: operator % – 1, вызовы функций – 5, конструкция with .. as – 1, обращение к полю/методу – 3, оператор [] – 1. for .. in – 1. Итого 12.

Racket: вызовы функций – 6, call-with-input-file – 1, lambda – 1, for/list – 1, match .. list – 1. Итого 10. Если для match и for/list считать каждое связывание переменной отдельной конструкцией, то 12.

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

Тогда можно считать, что гамильтонов путь из Racket доступен. Существует библиотека igraph (на C).

monk ★★★★★ ()

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

byko3y ()
Ответ на: комментарий от monk

А ты его точно из DrRacket запускал?

То было из консоли. Но из DrRacket ошибка была такой же. Запустилось только после выставления /bin/true в качестве браузера в настройках DrRacket.

В ракете (embed/url …) его делает автоматически. Соответственно, я могу передавать в качестве параметра любое замыкание (а в качестве связанных значений произвольные данные: ссылки на файлы, массивы, хэши, результаты запроса из БД, …).

А, теперь понятно, благодарю. В flask-е есть похожая url_for(), но она не добавляет объекты в сессию, а сериализует их в аргумент урла.

Я не знаю, есть ли готовая функция, которая сохраняет объекты в памяти, даже если они не сериализуются (в реальности это обычно не нужно, так что может и нет). Но навелосипедить это — пара строк:

from flask import Flask
app = Flask(__name__)

mem = {}

@app.route('/')
def start():
    f = open(__file__)
    mem[f.fileno()] = f
    return redirect('/%d' % f.fileno())

@app.route('/<int:fid>')
def phase(fid):
    return f'<html><body><h1>Phase 1</h1><p>{mem[fid].readline()}</p><a href="/{fid}">next line</a></body></html>'

if __name__ == '__main__':
    app.run()

Тогда можно считать, что гамильтонов путь из Racket доступен. Существует библиотека igraph (на C).

Да, это вполне подходит. Как будет выглядеть использующий её код?

Python: operator % – 1, вызовы функций – 5, конструкция with .. as – 1, обращение к полю/методу – 3, оператор [] – 1. for .. in – 1. Итого 12.

Racket: вызовы функций – 6, call-with-input-file – 1, lambda – 1, for/list – 1, match .. list – 1. Итого 10. Если для match и for/list считать каждое связывание переменной отдельной конструкцией, то 12.

Так не честно. 🙂 Если мы считаем синтаксические элементы, то должны считать всё, идентификаторы, открывающие и закрывающие скобки, разделители, и т.д... А хотя пусть будет... При удачно подобранных вызовах Racket не сильно сложнее Python-а.

Это, кстати, навело меня ещё на мысль: python проще racket-а потому, что в нём большее делается меньшим числом различных вызовов. Десяток вызовов Racket-а заменяет один open() Python-а.

В глобальной области видимости питона где-то полторы сотни идентификаторов: пол сотни исключений (ArithmeticError, ImportError, IOError...) ещё пол сотни встроенный функций (any, all, sum, min, max, len, open...), несколько десятков типов (bool, int, float, str, list, set, dict...) и несколько констант (None, True, False, Ellipsis, NotImplemented).

^ почти весь питон в одном предложении.

anonymous ()
Ответ на: комментарий от anonymous

Но навелосипедить это — пара строк

Вот я это и имел в виду. Что для каждого типа придётся велосипедить. Хорошо, у файла есть fileno.

Что будешь делать на часто используемую конструкцию типа:

(define ((get-query str) request)
  (define (response-generator embed/url)
    (response/xexpr
     `(html
       (body (h1 ,(format "You query " str))
             (table
               ,@(for/list ([row (get-data-from-db str)])
                 `(tr (td (a ((href ,(embed/url (show-row row)))) 
                             ,(presentation row))))))))))
  (send/suspend/dispatch response-generator))

? Велосипедить промежуточное хранилище данных с номерами строк?

Кстати, твой массив mem будет пухнуть. При закрытии файла (сборщиком мусора) из него автоматически позиция не удаляется.

monk ★★★★★ ()

Типичное уеб-приложение представляет собой небольшую прослойку между HTTP-сервером и базой данных, и его производительность ограничивается I/O на обоих концах, а отнюдь не скоростью работы самого кода. Проекты, в которых это не так, называют громким словом «хайлоуд», и даже в них (как и в любых софтовых проектах) производительность далеко не всего кода действительно критична, а есть определенные боттлнеки.

annulen ★★★★★ ()
Ответ на: комментарий от annulen

его производительность ограничивается I/O на обоих концах, а отнюдь не скоростью работы самого кода.

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

ya-betmen ★★★★★ ()
Последнее исправление: ya-betmen (всего исправлений: 1)
Ответ на: комментарий от ya-betmen

его производительность ограничивается I/O на обоих концах, а отнюдь не скоростью работы самого кода.

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

Пардон, а чем здесь отличается руби от питона или PHP? Руби не взлетел по совершенно другим причинам, ящитаю.

byko3y ()
Ответ на: комментарий от ya-betmen

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

WitcherGeralt ★★ ()
Последнее исправление: WitcherGeralt (всего исправлений: 2)
Ответ на: комментарий от anonymous

Если мы считаем синтаксические элементы, то должны считать всё, идентификаторы, открывающие и закрывающие скобки, разделители, и т.д…

Тогда для питона придётся пробелы в начале строки считать. Они ведь в нём синтаксически значимы.

python проще racket-а потому, что в нём большее делается меньшим числом различных вызовов.

Десяток вызовов Racket-а заменяет один open() Python-а.

Передёргиваешь. Вот вызовы с той страницы

open-input-file
open-output-file
open-input-output-file
call-with-input-file
call-with-output-file
call-with-input-file*
call-with-output-file*
with-input-from-file
with-output-to-file
port-try-file-lock?
port-file-unlock
port-file-identity

Последние три, очевидно, к открытию файла не относятся. Конструкции with-… в питоне вроде невозможны. Или что написать, чтобы работало

with .... open("file.txt"):
  print "ok"

и это «ok» записалось в файл, а не стандартный вывод?

Для аналога call-with…* в питоне требуется конструкция with .. as, а не только open.

Аналога call-with… (без звёздочки) в питоне не существует. Правда в нём и нет, потребности, так как продолжение сохранить невозможно.

Остаётся три функции на open и две функции на with/as. Уже не один к десяти.

Кроме того, как при помощи open реализовать

(open-output-file #:exists 'must-truncate)
(open-output-file #:exists 'truncate/replace)
(open-output-file #:exists 'update)

?

monk ★★★★★ ()
Последнее исправление: monk (всего исправлений: 1)
Ответ на: комментарий от monk

А что не так? По твоей ссылке swoole на PHP имеет 307 тысяч попугаев, uvicorn на питоне – 72 тысячи, roda на руби – 60 тысяч.

https://www.techempower.com/benchmarks/#section=data-r18&hw=ph&test=u...
А так? Swoole оптимизирован под конкретные запросы, а на обновлениях он оказался не оптимизирован и вперед вышли фреймворки на питоне. Причем, питонофреймворки вышли скопом, а Swoole лидирует почему-то единственный среди всех использующих PHP.

byko3y ()
Ответ на: комментарий от ya-betmen

Тогда это рассуждения уровня «C отжал у хаскеля системное программирование».

Питон изначально был простой и удобной системной скриптотой, а руби ООП-heavy язык ради языка. У них не было никакой общей ниши и не могло, а встретились они в точке пересечения RoR и Django.

WitcherGeralt ★★ ()
Ответ на: комментарий от WitcherGeralt

Питон изначально был простой и удобной системной скриптотой

Настолько же, насколько и PERL. И вытеснял PERL (и боролся с PHP) из веба задолго до появления Django. Тогда у питона был Zope.

monk ★★★★★ ()
Последнее исправление: monk (всего исправлений: 1)
Ответ на: комментарий от byko3y

Загадочно. На https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/php.html питон определённо медленней. Могу предположить, что в среднем уровень программистов на питоне выше, чем уровень программистов на пхп.

monk ★★★★★ ()
Ответ на: комментарий от WitcherGeralt

Гм. Я против утверждения: «У них не было никакой общей ниши и не могло, а встретились они в точке пересечения RoR и Django.».

В тот момент, когда появился RoR, питон уже очень прочно сидел в этой нише (и Zope такой же ООП-heavy как и руби). И RoR сначала его достаточно сильно потеснил. Но потом в питон добавили кучу новых конструкций, сделали питон3 и синтаксические преимущества ruby стали гораздо менее явными. Ситуация примерно аналогична с Java и C#.

monk ★★★★★ ()
Последнее исправление: monk (всего исправлений: 1)
Ответ на: комментарий от monk

Загадочно. На https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/php.html питон определённо медленней. Могу предположить, что в среднем уровень программистов на питоне выше, чем уровень программистов на пхп.

Я бы мог заметить, что ни один из бенчей не использует нумпи, который отлично подходит для векторных выичслений в примерах, но я согласен и на «питон в полтора-два раза медленнее, чем PHP». И чо дальше? Это плюс-минус ничего для тех ниш, где они использовались, потому что еще есть канал, а еще есть база данных, а питон/пых, зачастую, служат лишь прослойкой.

byko3y ()
Ответ на: комментарий от monk

Но потом в питон добавили кучу новых конструкций, сделали питон3

Это «потом» было чуть ли не вчера. И это никак не относится к джанге. Очень многие, включая гигантов типа мейлру, до сих пор сидят на ней и 2.7, а там хоть и был некий качественный скачёк, в сущности ничего критичного относительно 2.5 не произошло.

WitcherGeralt ★★ ()
Ответ на: комментарий от byko3y

я согласен и на «питон в полтора-два раза медленнее, чем PHP». И чо дальше?

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

ya-betmen ★★★★★ ()