у крестов стандарты есть, но ни один из них не описывает UI и средства работы с ним.
HTML/CSS тоже не описывают UI, это средства разметки текста. То, что там есть полтора виджета стандартных, вовсе не делает это говно пригодным для UI. По факту получается тот же зоопарк, что и с гуи-тулкитами, только гораздо хуже в плане реализации. В общем, удачи делать хоть сколько-нибудь сложный UI на голом html с ванильным js.
Благодаря вебу мы вместо зоопарка кути и гтк девелоперов получили зоопарк кути, гтк и электрон-девелоперов.
Все гораздо хуже, потому что электрон это не обычный тулкит, а еще один зоопарк для жснутых. Так что получили зоопарк в зоопарке. Как раз самая жопа с вебней в том, что никаких стандартных (хоть бы и де-факто) решений для UI там нет, только DOM и скриптуха - дальше крутись как хочешь.
Зачем компилировать js в машкоды? Браузеры и без этого решето.
Транспилятор js->js (prepack.io) — сырая поделка, не умеющая ничего готового для продакшн.
Другой транспилятор почти-js->js (typescript) — делает код чуть жирнее и чуть медленнее в обмен на удобство разработки.
Третий транспилятор js->js (babel) — тормозная поделка сама по себе, да ещё и делает код, как правило, медленнее.
Транспилятор что-нибудь->js (да хотя бы ocaml) — умеет в статический анализ кода и в оптимизации на основе этого. В конце концов, позволяет record’ы и enum’ы без накладных расходов (а не как тайпскрипт) за счёт не настолько удобного interop’а с прочим жабоскриптом. И всё это работает быстрее, чем babel или typescript-компилятор.
WAsm и asm.js исполняются не на жаваскрипте - что не так?
Во-первых, то не так, что эта фраза — шизофазия. А во-вторых эти инструменты и возникли и являются частью именно javascript-мира. При этом ты заявляешь, что js не развивается и устарел. Ну это же ЛОЛ. js не только очень развитая и передовая платформа, а вообще двигатель прогресса. Поэтому я и спрашиваю, каких таких инструментов ты хочешь? Покажи что есть лучше за пределами js и иже с ним?
Зачем компилировать js в машкоды? Браузеры и без этого решето.
Это делают JIT-компиляторы всех быстрых движков JS, получая производительность примерно 1/4 от кода на С с ручным управлением памятью.
Другой транспилятор почти-js->js (typescript) — делает код чуть жирнее и чуть медленнее в обмен на удобство разработки.
Ты не осознаешь, что тайпскрипт умеет статически анализировать жавоскрипт.
Транспилятор что-нибудь->js (да хотя бы ocaml) — умеет в статический анализ кода и в оптимизации на основе этого. В конце концов, позволяет record’ы и enum’ы без накладных расходов (а не как тайпскрипт) за счёт не настолько удобного interop’а с прочим жабоскриптом. И всё это работает быстрее, чем babel или typescript-компилятор
У меня есть сомнения по поводу быстроты, как транспилирования, так и работы конечного кода, но я бы сказал это это не важно и у JS всегда есть верхняя планка скорости, выше которой ты не сможешь прыгнуть никакими способами. А важно удобство разработки, важна поддерживаемость, важна возможность перейти на новую версию библиотек, не выполняя заново длительной ручной отладки кода, важно иметь возможность кинуть кусок кода из одного модуля в другой и иметь гарантию, что этот кусок будет работать, важно уменьшить излишние конструкции в коде, сделав его чистым, читаемым, понятным, и при этом с гарантированным поведением. С этим всем есть большие проблемы у JS, из-за чего постоянные внезапные отвалы кода, ошибки, трудности организации кода.
Зачем писать на js?
Вот я пишу на JS. Но у меня нет выбора: vue.js адекватно поддерживает только его. Typescript в полукостыльном виде только-только вводят.
А во-вторых эти инструменты и возникли и являются частью именно javascript-мира.
Ты бы еще написал «являются проявлением javascript-любви, javascript-достоинства». А потом еще меня в шизофазии обвиняет. Выдумал себе какой-то javascript-манямирок, и проецирует его на меня.
При этом ты заявляешь, что js не развивается и устарел
Жаваскрипт развивается и устарел. Отсюда массово возникают альтернативные платформы, на которых нельзя исполнить javascript, хоть они очень часто и взаимодействуют тесно с JS, поскольку в текущее время это единственная общепринятая среда выполнения для браузеров. Тот же WebAssembly не может исполнить JavaScript, но для взаимодействия с браузером кода на WAsm используют именно JS. asm.js, хоть и может быть исполнени в обычном движке JS, но смысл обретает только в совершенно ином режиме компиляции AOT на специальном движке, который опять же не поддерживает обычный JavaScript, то есть, это уже не жаваскрипт, а новый язык, который из соображений совместимости сделали синтаксически похожим на JS.
Да, но только я вот прямо сейчас могу взять любую страничку из тырнетов и применить к ней кастомный CSS, и болт класть на то какой там модный очередной UI фреймворк. Потому что стили применяются к DOM, а не к васипупкинскому творению. Удачи проделать то же самое на десктопе. То, как нечто похожее попыталиь запилить гтк и кути - лучше бы и не пытались.
Да, но только я вот прямо сейчас могу взять любую страничку из тырнетов и применить к ней кастомный CSS, и болт класть на то какой там модный очередной UI фреймворк.
Во первых, не можешь, потому что очередной UI фреймворк твой кастомный цсс затрёт своим цсс-ин-жс. Во вторых, нахуя?
Да пофигу чем там генерится CSS и в зависимости от каких условий. Важно то, что на каждом из стопицотмильонов сайтиков все тот же DOM и все тот же CSS, и это дает возможность настраивать UI прямо здесь и сейчас. Стандартным образом, да.
На Python просто библиотек больше, там все программы состоят в основном из import крутая_библиотека, всё остальное делают сами библиотеки. Никого не беспокоит производительность программы, пока её можно слепить из готовых библиотек за пару минут поиска нужных клавиш для набора названий этих библиотек… Ненавижу питон, он своими библиотеками мешает писать велосипеды, а какой смысл в программировании, если нельзя писать велосипеды?
Значит, нету у тебя x-www-browser. Надо в DrRacket в Настройки пользователя/Браузер указать, что у тебя есть. Или просто вручную в любом браузере вбить этот URL.
По буквам — да. По количеству синтаксических элементов примерно одинаково. Если стремиться к компактности по буквам, то идеал — Perl, а ещё лучше APL. Python в своё время победил Perl, несмотря на то, что почти весь код становился примерно в два раза длиннее.
Удобство языка, во многом, определяется наличием нужных библиотек.
Тогда бы мы до сих пор писали на фортране и коболе, как самых удобных (читай «имеющих нужные библиотеки») языках.
$ 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, в том числе и в питоне.
Библиотека не обязательно должна быть переписана на этом языке, достаточно чтобы она была из него доступна.
В каком смысле? В ракете он разве не точно так же явно указан?
В ракете (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).
Соревнование запускалок. Как мило. Как по мне - особо разницы нет, я бы и на перле, и на скиме писал. Естественно, под питон больше инструментов, ибо спрос рождает предложение, а я уже, лично, устал хардкорить. Можно, безусловно, можно писать новый проект на перле, можно писать на ским/ракет, но вам нужно набрать команду аутистов, которые будут уметь на этих языках писать. Можете попробовать открыть биржи и поискать спецов по теме.
То было из консоли. Но из 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).
Типичное уеб-приложение представляет собой небольшую прослойку между HTTP-сервером и базой данных, и его производительность ограничивается I/O на обоих концах, а отнюдь не скоростью работы самого кода. Проекты, в которых это не так, называют громким словом «хайлоуд», и даже в них (как и в любых софтовых проектах) производительность далеко не всего кода действительно критична, а есть определенные боттлнеки.
На самом деле рельсы и джанго появились одновременно, и изначально рельсы взлетели даже выше. Сейчас руби нафиг никому не нужны, но сайтов на них запиленных до сих пор крайне дофига. Те же гитхаб и гитлаб, которые ещё долго никуда не денутся.
А что не так? По твоей ссылке swoole на PHP имеет 307 тысяч попугаев, uvicorn на питоне – 72 тысячи, roda на руби – 60 тысяч.
https://www.techempower.com/benchmarks/#section=data-r18&hw=ph&test=u...
А так? Swoole оптимизирован под конкретные запросы, а на обновлениях он оказался не оптимизирован и вперед вышли фреймворки на питоне. Причем, питонофреймворки вышли скопом, а Swoole лидирует почему-то единственный среди всех использующих PHP.
Тогда это рассуждения уровня «C отжал у хаскеля системное программирование».
Питон изначально был простой и удобной системной скриптотой, а руби ООП-heavy язык ради языка. У них не было никакой общей ниши и не могло, а встретились они в точке пересечения RoR и Django.
Гм. Я против утверждения: «У них не было никакой общей ниши и не могло, а встретились они в точке пересечения RoR и Django.».
В тот момент, когда появился RoR, питон уже очень прочно сидел в этой нише (и Zope такой же ООП-heavy как и руби). И RoR сначала его достаточно сильно потеснил. Но потом в питон добавили кучу новых конструкций, сделали питон3 и синтаксические преимущества ruby стали гораздо менее явными. Ситуация примерно аналогична с Java и C#.
Я бы мог заметить, что ни один из бенчей не использует нумпи, который отлично подходит для векторных выичслений в примерах, но я согласен и на «питон в полтора-два раза медленнее, чем PHP». И чо дальше? Это плюс-минус ничего для тех ниш, где они использовались, потому что еще есть канал, а еще есть база данных, а питон/пых, зачастую, служат лишь прослойкой.
Но потом в питон добавили кучу новых конструкций, сделали питон3
Это «потом» было чуть ли не вчера. И это никак не относится к джанге. Очень многие, включая гигантов типа мейлру, до сих пор сидят на ней и 2.7, а там хоть и был некий качественный скачёк, в сущности ничего критичного относительно 2.5 не произошло.
я согласен и на «питон в полтора-два раза медленнее, чем PHP». И чо дальше?
Это только в изолированных бенчах. В реальности в пыхе разработчик не сталкивается с многопоточкой, что при примерно одинаковом уровне людей дает заметную разницу.