История изменений
Исправление byko3y, (текущая версия) :
У лиспа он есть всегда. И, в частности в eval можно изменить любую функцию
Да ладна тебе — есть же компиляторы, которые выдают чистый натив.
Но, вполне возможно, будет мономорфизоваться.
То есть на каждую комбинацию типов по новому экземпляру?
Конечно нет — есть определенные эвристические алгоритмы, которые определяют, когда уже «много», а когда еще «мало». Например, V8 не оптимизирует функции, у которых больше пяти аргументов.
но PyPy требует сильно больше ресурсов на разработку, чем V8 — как я писал, даже у гугла столько ресурсов нет.
Вот опять скорость программы зависит от языка при равных алгоритмах в компиляторе
А ты не задумывался о том, что писать JIT-оптимизатор для JS — это чудовищно дорого и неэффективно? Кто вывалил бабки — у того язык и бегает быстрее. Google решил, что оптимизировать JS дешевле, чем питон — но в любых раскладах и то, и то очень дорого. Как я уже писал, язык определяет цену, но цена эта всегда большая.
Написать интерфейс на жаве намного сложнее, чем нарисовать его на HTML. Поэтому делали только там, где за это платили много денег. С таким же успехом можно интересоваться, почему на Си так мало сайтов
Не согласен. Hello world на обоих инструментах сделать несложно. По мере роста сложности выясняется, что у веб браузера удивительно ограниченный набор выразительных средств: ты можешь нарисовать статичную страничку с картинками, но любая минимально нестандартная логика требует кучи кода. Например, ты не можешь сделать развитую работу с текстом — по этой причине уже есть либы на чистом JS, которые умеют грузить и отрисовывать шрифты TrueType/OpenType/WOFF. Сделать кастомный разделитель блоков с изменением размера или даже банальную нестандартную логику полоскы прокрутки — снова приходим к голому JS и обработке низкоуровневых событий мыши (mousedown/mousemove/mouseup).
По факту, если ты посмотришь, что же легко пишется на Electron и пользуется популярностью, то увидишь какие-нибудь месенджеры, чатики, софтины для заметок, в том числе для коллективной работы с заметками, клиенты почты — то есть, всё то, что большую часть времени просто рисует HTML. Но даже Telegram написан на крестах-Qt, потому что огромное количество логики для ихнего протокола писать на JS тяжело и работать это будет медленно, а HTML может отобразить и Qt. Нет, IDE не легко пишется на электроне, там буквально каждую буковку приходится отдельно рисовать на JS и каждое движение мышки обрабатывать на JS, и даже после долгой и нудной работы не всё работает гладко, потому что JS не располагает к стабильности и поддерживаемости кода. Потому VS Code написан на TS и работает значительно стабильнее, чем Atom. Нет, фотошоп (Photopea) требует огромного количества библиотек и рисование на HTML5 Canvas «с нуля» на JS. Google Docs тоже всё форматирование документов сделали с нуля на JS.
По факту, Electron — это удобный инструмент только если тебе нужно отобразить по большей части статичную HTML страничку.
Если у кого-то стоит задача разработки win-only гуя, то тут выбор однозначен: Electron отправляется в мусорку и берется WPF.
Это что, killer app? Скринсейвер для тех, кто не научился в отключение экрана по бездействию?
Но без дополнительных настроек на достаточно большом классе задач GC может работать быстрее чем malloc/free или new/delete
Спорное заявление, если принять во внимание современные менеджеры памяти с детерминированным O(1) выделения и высвобождения, с минимальной фрагментацией и хорошей масштабируемостью многопотока. В число которых, как я уже писал, не входит стандартный менеджер glibc — который оптимизирован на минимизацию потребления памяти, а не на производительность.
Исходная версия byko3y, :
У лиспа он есть всегда. И, в частности в eval можно изменить любую функцию
Да ладна тебе — есть же компиляторы, которые выдают чистый натив.
Но, вполне возможно, будет мономорфизоваться.
То есть на каждую комбинацию типов по новому экземпляру?
Конечно нет — есть определенные эвристические алгоритмы, которые определяют, когда уже «много», а когда еще «мало». Например, V8 не оптимизирует функции, у которых больше пяти аргументов.
Написать интерфейс на жаве намного сложнее, чем нарисовать его на HTML. Поэтому делали только там, где за это платили много денег. С таким же успехом можно интересоваться, почему на Си так мало сайтов
Не согласен. Hello world на обоих инструментах сделать несложно. По мере роста сложности выясняется, что у веб браузера удивительно ограниченный набор выразительных средств: ты можешь нарисовать статичную страничку с картинками, но любая минимально нестандартная логика требует кучи кода. Например, ты не можешь сделать развитую работу с текстом — по этой причине уже есть либы на чистом JS, которые умеют грузить и отрисовывать шрифты TrueType/OpenType/WOFF. Сделать кастомный разделитель блоков с изменением размера или даже банальную нестандартную логику полоскы прокрутки — снова приходим к голому JS и обработке низкоуровневых событий мыши (mousedown/mousemove/mouseup).
По факту, если ты посмотришь, что же легко пишется на Electron и пользуется популярностью, то увидишь какие-нибудь месенджеры, чатики, софтины для заметок, в том числе для коллективной работы с заметками, клиенты почты — то есть, всё то, что большую часть времени просто рисует HTML. Но даже Telegram написан на крестах-Qt, потому что огромное количество логики для ихнего протокола писать на JS тяжело и работать это будет медленно, а HTML может отобразить и Qt. Нет, IDE не легко пишется на электроне, там буквально каждую буковку приходится отдельно рисовать на JS и каждое движение мышки обрабатывать на JS, и даже после долгой и нудной работы не всё работает гладко, потому что JS не располагает к стабильности и поддерживаемости кода. Потому VS Code написан на TS и работает значительно стабильнее, чем Atom. Нет, фотошоп (Photopea) требует огромного количества библиотек и рисование на HTML5 Canvas «с нуля» на JS. Google Docs тоже всё форматирование документов сделали с нуля на JS.
По факту, Electron — это удобный инструмент только если тебе нужно отобразить по большей части статичную HTML страничку.
Если у кого-то стоит задача разработки win-only гуя, то тут выбор однозначен: Electron отправляется в мусорку и берется WPF.
Это что, killer app? Скринсейвер для тех, кто не научился в отключение экрана по бездействию?
Но без дополнительных настроек на достаточно большом классе задач GC может работать быстрее чем malloc/free или new/delete
Спорное заявление, если принять во внимание современные менеджеры памяти с детерминированным O(1) выделения и высвобождения, с минимальной фрагментацией и хорошей масштабируемостью многопотока. В число которых, как я уже писал, не входит стандартный менеджер glibc — который оптимизирован на минимизацию потребления памяти, а не на производительность.