Сообщение от voraa Нет. Браузер не для того, что бы быстро считать.

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

0

Браузеры и так довольно сложные.
Если в приложении нужны какие то быстрые расчеты - для этого есть другие инструменты - тот же webassembler.
Раньше ходили разговоры, о том, что бы кешировать скомпилированный байт-код - это бы ускорило работу, но чего то разговорами и осталось.

Добавлено через 3 минуты

Сообщение от testuser2 А почему нет, игры, видики-шмидики, современные веб-страницы - ведь это приложения,

Ну есть статистика. Какой % занимают браузерные игры во всем количестве сайтов и показов. Для видео js не нужен. Он там никак не участвует. И даже в современных сайтах приложениях основное время тратится не на работу js, там нет никаких тяжелых вычислительных алгоритмов. Основное - запрос на сервер - получение ответа, работа с DOM.

0

Сообщение от voraa для этого есть другие инструменты - тот же webassembler.

Но webassembler это уже кот в мешке, уже сложно анализировать, опасность вирусов, Мурыч об этом говорил.

0

Сообщение от testuser2 Но webassembler это уже кот в мешке, уже сложно анализировать,

А кому анализировать?
Ты пишешь код, который что то должен быстро посчитать. Скажем на C. транслируешь в wasm. Кто там что анализировать должен?

0

Сообщение от voraa транслируешь в wasm. Кто там что анализировать должен?

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

0

Сообщение от testuser2 не крадет ли этот код данные, я предполагаю,

Он делает не больше, чем может делать js (реально даже меньше) и что разрешает делать браузер. Он просто быстро считает.
Ты же не анализируешь код js открывая какую-нибудь страницу.

0

Сообщение от voraa быстрые расчеты - для этого есть другие инструменты - тот же webassembler

С каких пор webassembly стал быстрым? Он как минимум для работы требует сервера (ограничения js не может читать файлы) и работает в виртуальной машине вместе с js. Его преимущества перед js только в том что он бинарный, а так по сути тот же js, среда исполнения та же. Глубоко не углублялся, но вроде даже тот же js и исполняет этот wasm

0

Мне вот интересно как это работает, когда я открываю данную страницу https://pez.github.io/language... #fibonacci, которая по сути статична (я там ни чего не трогаю). Но пока эта страница хотябы частично на виду, процессор моего ноутбука грузится под 50%. Если я сворачиваю или перекрываю все каким-нибудь другим окном, процессор успокаивается. Это какие-то js-"трюки"?

Добавлено через 30 минут
Нейросеть подсказала использовать "профайлер" и кстати по нему видно источники загрузки это Dom и JS кстати тоже не малой частью.

0

Сообщение от korvin_ А если Делфи так хорош, чего не купили лицуху? Или всю Ембаркадеру?

А давайте разберем зачем Гугл вообще сделал Go и что это такое. А это просто еще одно урезание C++ по самое не могу с добавлением многопоточности. Хотя мне непонятно, почему многопоточность должна быть на уровне языка, а не библиотек. Понятно, что никакой сторонний язык Гугл приобретать бы не стал, им и западло, и язык им был нужен маленький. Но, по факту, оказывается, что C++ вокруг которого 30 лет назад хороводы водили, оказывается плохой, т. к. на нем писать сложно, долго и дорого, JVM и .NET оказывается не нужны, это просто громоздкая хрень, которая, по факту, никаких проблем не решает. Сборщик мусора разве что, хотя реальная его полезность вызывает определенные сомнения, ну на задачах, для которых Go делали, от него вред невелик.

А почему C++ плохой? Потому что адресная арифметика! Там можно наошибаться так, что потом не задебажишь. Сюрприз, но в Паскале тоже всегда была адресная арифметика в том или ином виде (т. е. арифметические операции над Pointer могли быть запрещены. но преобразование в Integer нет), в Delphi 2009 она вообще узаконена полностью, только по дефолту отключена, нужно директивой включать. Но в Паскале никто на работу с памятью не жалуется. Почему? А потому что большинство операций, где она могла бы потребоваться, закрыты синтаксическими конструкциями. Не надо писать, что передаете указатель на что-то как параметр, пишите просто var, массивы не аналогичны указателям и т. д. Соответственно в практической работе всегда есть грань между безопасным и опасным, которой при постоянной работе с памятью, как проходным двором нет, и программисты, имея возможность работы с памятью, никогда не делают это просто так.

C создавался для системного программирования, там свободная работа с памятью и готовность к последствиям нормальны, но как вообще могла прийти в голову идея смешивать язык низкого уровня и высокоуровневую концепцию типа ООП? Построить вокруг такой химеры индустрию, а потом внедрять в энтерпрайз Java, язык из которого убрали всё, на чем программист ломает ноги, да еще и в виртуальную машину засунуть, так что работает это всё со скоростью улитки, потом делать аналог Паскаля с фигурными скобками и тоже с виртуальной машиной, а в итоге дойти до Go и Питона. Из всего этого можно сделать вывод, что вся концепция развития программирования за последние 30-40 лет просто-напросто жидко обделалась, будучи построенной с одной стороны на абсолютно неверно спроектированном языке, а с др. на постоянных попытках порезать этот язык, чтобы программисты могли работать, а не соревноваться в выпендреже. При этом производительность C++, которая уже вызывает сомнения в силу распространения LLVM-компиляторов, оказывается просто не востребована даже там, где вроде бы нужна, как в том же Unreal Engine, т. к. для достижения хороших результатов разработчик приложения должен лезть в движок, а программистов, хорошо знакомых с C++, уже не хватает.

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

1

Сообщение от Beltar А ты каждое изучал, на чем написано?

Мне не за чем. Ты говоришь, что Делфи популярен и распространён в разработке мобильных приложений (чайник Рассела). Доказывай.

Наличие (большого количества) приложений на Swift и Java/Kotlin доказывать не надо, это стандартные языки для разработки приложений под мобильные платформы. Можешь зайти в соответствующие разделы форума и погуглить. Ну и выше писали про игры на C#/Unity. Есть ещё React Native, но я не знаю, насколько он распространён в этой сфере.

Можно ещё по вакансия глянуть, какие стэки технологий требуются для мобильных разработчиков. Сомневаюсь, что там много где требуется Delphi, возможно, что и нигде.

0

Delphi начал продаваться с подпиской.
Это его удорожает в долговременной перспективе.
Я понимаю, что софт коммерческий, затраты, а на Lazarus трёхзвенку не напишешь.
В Delphi, однако, можно скомпилирповать COM+ И даже COM.
И используй транзакционный сервер.
Или там есть ещё какие-то компоненты для этого, прошу гуру разъяснить.

Добавлено через 27 минут
Нашёл пакет LazActiveX.
А невизуальный объект, который можно загрузить на MTS(Microsoft Transaction Server)?

Добавлено через 6 минут
И вообще, LazAxtiveX - это использование ActiveX в Lazarus.
А как скомпилировать COM?

Добавлено через 4 минуты
В принципе, DLL Lazarus компилировать умеет.
Но мне нужен COM+ (или хотя бы COM) объект в DLL.
И чтобы его зарегистрировать в системе с последующим использованием его на сервере транзакций.
Потом, какой это будет DLL - 32 или х86_64?

0

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

Нет, я такого не говорил, мне неизвестна статистика. Я говорил, что Delphi для этого применяется, и направление это там взято как бы еще в 2011-ом году, и до сих пор не закрыто. Какой процент мобильных приложений написан на Delphi? Может 1%, а может 10%. Прикол в том, что даже 1% от богатого рынка - это огромная величина, и у Delphi точно так же остаются и 100500 легаси-приложений, и десктоп, и веб-сервисы. Но ведь мобилки разные, есть андройд, есть iOS. Есть MacOS еще и там собственные средства разработки, насколько я понимаю, не бог весть что. А Xamarin, например, что умеет, кроме мобилок?

Сообщение от Ludwig Valentin Или там есть ещё какие-то компоненты для этого, прошу гуру разъяснить.

Компоненты для COM-серверов MS Office есть, а для создания зачем компоненты? В книге Фаронова по которой я учился, по COM'у целый раздел, но свои COM'ики писать не приходилось, не скажу, как это делается, импортировать готовые ActiveX приходилось, по ним дельфа умеет заголовочный файл автоматом создавать.

0

Сообщение от alecss131 С каких пор webassembly стал быстрым?

webassembly практически сразу компилируется в нативный код процессора. Ему не надо ждать "разогрева" функции, как в js (а это несколько тысяч вызовов)
Среда исполнения одна - браузер. Но компоненты среды разные. В V8 (Хром) это так работает
JS:
Парсер строит AST
Интерпретатор Ignition компилит по AST байт-код и исполняет (интерпретирует) его.
Горячие функции передаются в TurboFan (оптимизирующий компилятор), который генерит для них нативный код.

WASM:
Файл передается в базовый компилятор Liftoff, который генерит нативный, но не оптимальный код. (Но нативный код все равно прямо на первой стадии)
Горячие функции передаются в TurboFan , который генерит оптимизированный нативный код.

0

Сообщение от Beltar Компоненты для COM-серверов MS Office есть, а для создания зачем компоненты? В книге Фаронова по которой я учился, по COM'у целый раздел, но свои COM'ики писать не приходилось, не скажу, как это делается, импортировать готовые ActiveX приходилось, по ним дельфа умеет заголовочный файл автоматом создавать.

Трёхзвенка.
Например, я хочу получить аналог JavaBeans для таблицы SQL.
Пишу серверный COM, в который заливаю данные и размещаю на транзакционном сервере.
Это как Middleware.
Пишу морду на Lazarus, подключаюсь к серверному объекту и вывожу из него данные на форму.

0

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

Потому, что так проще. И все оптимизации и необходимые проверки делаются 1 раз на уровне исполнительной системы. И каждый программист этим заниматься не должен.

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

Ну его и делали для определенных задач, с которыми он прекрасно справляется. Как универсальный ЯП его никто не позиционировал. ОС на нем писать не будут. GUI - сомневаюсь, а вот нагруженные CLI, сервера и сервисы - пожалуйста.
А если сравнивать по производительности, я не видел сравнения с Дельфи. С С и Rust сравнивали. Вроде GO уступает, но совсем чутка - единицы процентов.

И, кстати, как Делфи себя чувствует на ARM? Сервер, написанный на Дельфи на ARM перенести можно?

Добавлено через 7 минут

Сообщение от Beltar А почему C++ плохой? Потому что адресная арифметика!

В ней нет ничего плохого при разумном использовании. Но позволяет сильно оптимизировать код. Да, у С есть недостаток, что позволяет ее бездумно использовать где надо и не надо. Ну поэтому в др. языках и стали создавать трудности в виде всяких unsave.

Добавлено через 16 минут

Сообщение от Beltar А это просто еще одно урезание C++ по самое не могу

Не только. В Go еще концепция - отсутствие всяких библиотек и зависимостей. На выходе просто получается самодостаточный исполняемый файл.

0

Сервер приложений EAServer от Sybase.
Правда, последняя версия 32 бит, давно не обновлялся.
Есть сервера приложений чисто для Java.

0

Сообщение от Beltar есть iOS. Есть MacOS еще и там собственные средства разработки, насколько я понимаю, не бог весть что

У яблочных устройств все общее, общая IDE по дназванием XCode для C/C++/Objective-C/Objective-C++/Swift, в которой создаются и собираются проекты под все устройства. А с выходом SwiftUI (декларативный UI фреймворк, аналог Jetpack Compose у котлина с андроидом и мультиплатформой, но у яблок это часть ОС) можно один и тот же код без правок собирать и под десктоп и под мобилки. Графическое апи (которое может быть низким как вулкан или простым как opengl) Metal так же работает везде без правки кода. Разное было только в UI Kit, Interface Builder, Storyboard и XIB но и то различие было в разных импортах и названиях классов.
Swift сейчас опенсорсный и кроссплатформенный, но гуи на других ос печально все, а на винде не работают некоторые либы (например сетевые). У языка есть уже свои веб фреймворки для бэкэенд разработки. Язык очень даже ничего, без сборщика мусора, нативно компилируемый и безопасный, хорошо сочетается с с/с++.

Сообщение от Beltar как в том же Unreal Engine, т. к. для достижения хороших результатов разработчик приложения должен лезть в движок

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

0

Сообщение от alecss131 Там в движок лезть не надо

Специалисты говорят, что для хорошего результата надо.

Сообщение от voraa В Go еще концепция - отсутствие всяких библиотек и зависимостей. На выходе просто получается самодостаточный исполняемый файл.

Ну полная статическая линковка всего, ну, допустим. Всегда ли это надо? Но для больших проектов он и не позиционируется.

Сообщение от voraa И, кстати, как Делфи себя чувствует на ARM? Сервер, написанный на Дельфи на ARM перенести можно?

Ну андройдные мобилки же на ARM работают.
https://docwiki.embarcadero.co... om_Desktop

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

Если другие ОСи на ARM, то тут не уверен.

Сообщение от voraa В ней нет ничего плохого при разумном использовании. Но позволяет сильно оптимизировать код. Да, у С есть недостаток, что позволяет ее бездумно использовать где надо и не надо. Ну поэтому в др. языках и стали создавать трудности в виде всяких unsave.

Это не вопрос плохости, это вопрос необходимости работы на низком уровне. Хотя в ряде случаев тоже можно извернуться, я, например, полученные пакеты байтов с COM-порта всегда маппил на юнионы, и я не понимаю, почему эта штука сейчас deprecated, проще, чем по байтовому массиву ходить.

Вопрос с оптимизацией не мешал даже в древние времена создаваться языкам, которые не про скорость. Фортран и Алгол-60 на фоне ассемблеров были не про скорость исполнения. Но уже в начале 1960-ых кризис случился, когда скорость написания кода упала до 3-5 операторов в день. Это решали структурным программированием. Скорость выполнения можно увеличить, создав более быстрый компьютер, и это надо сделать 1 раз, а вот программ надо писать много. К середине 90-ых на 100 МГц проце можно уже особо такты не считать, на десктопе софтине, в принципе, достаточно, успевать реагировать на действия пользователя. И вся эти Delphi, C# и прочие Visual Basic'и с жабами распространились именно поэтому, что скорость выполнения кода в подавляющем большинстве случаев перестала иметь значения, важнее стала скорость написания. Т. е. ниша, где вся эта мегаоптимизация C++ имела значение, уже к 2000-му году скукожилась. При этом совсем не факт, что другой язык, если вбухать столько же ресурсов в оптимизацию его компиляторов, показал бы себя в производительности хуже. Не интересовался глубоко вопросом, за что купил за то и продаю, но насколько я знаю, те же ранние движки от Id Software, после их публикации, переписывались на Delphi и оказывались не медленнее.

В современных же играх ситуация такова, что, как правило, всё упирается в видеокарту, но бывает, что и с производительностью по CPU всё плохо. Например, кто мне может объяснить, почему в 2001-ом году я без всяких лагов играл на своем первом Celeron-466 в Age of Wonders, написанную на Delphi 4 на карте на 12 игроков с одновременными ходами (она первая пошаговая стратегия, где это появилось), а в 2025-ом я, вынужден брать Ryzen 7700, чтобы у меня в написанной на C++ Age of Wonders 4 хотя бы не тормозили сражения 18 на 18 юнитов? При чем играю с классическими ходами на стратегической карте. И она не одна такая, дорогущая Baldur's Gate 3 тоже тормозит в поселениях, как не в себя. Может не работу с памятью надо оптимизировать, а распределение вычислительной нагрузки? Да и оптимизация компиляторов не имеет такого уж большого значения, когда надо не определитель от матрицы 100x100 найти, а крайне гетерогенный код выполнять.

0

Сообщение от Beltar Но для больших проектов он и не позиционируется.

Docker - большой проект?
А облако Яндекса?

Сообщение от Beltar Всегда ли это надо?

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

Сообщение от Beltar Фортран и Алгол-60 на фоне ассемблеров были не про скорость исполнения.

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

Сообщение от Beltar Скорость выполнения можно увеличить, создав более быстрый компьютер

Ну как бы владельцу сервера это может вылиться в копеечку. Туже задачу можно решить распараллеливанием (что в GO решается на автомате)

Сообщение от Beltar на десктопе софтине, в принципе, достаточно, успевать реагировать на действия пользователя.

Так у языков разные сферы применения. Может Дельфи и смотрится прекрасно на десктопе и реагирует без тормозов. А как он себя поведет на сервере с десятками тысяч запросов в секунду? А как он будет решать систему диф. уравнений, где расчет может идти несколько суток?

0

Если в языке нет энумов, то это уже так себе )

0