Ну вот, снова не тот бенчмарк. О чем речь. Зачем тогда просишь "показать код" ?
P>>Уже давно на бакенде. ·>В бекенд чего только не тащат, даже php. Это не значит, что оно того стоит.
Наоборот.
P>>Зачем? Ты все равно выкусишь то, что тебе удобно. P>>Бенчмарков было больше одного. Из них ты ожидаемо выбрал тот, где либа и проигнорил те, что без либы. P>>Какой смысл доказывать тебе? ·>Ты конткест потерял. Перечитай что тут обсуждается.
Я тебе просто пример, как ты откидываешь аргументы на любую тему. Собственно, в прошлый раз было ровно то же. Какой в этом смысл?
P>>·>Ну да, поэтому и используют обёртки подобные IList. P>>Ну да, компенсируют проблемы языка. ·>Языком компенсируют проблемы языка?! Это как?
"используют обёртки" == компенсируют проблемы языка. Или, по твоему, обертки сами себя используют?
Здравствуйте, Pauel, Вы писали:
P>>>https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/spectralnorm-node-7.html P>·>Ок. Похоже node осилил jit плоских циклов с байт-буферами. Не очень ясно, почему в коде явы массивы в цикле выделяются, поэтому какое-то непонятное сравнение. Для систем с jit такой бенчмарк мало что показывает. Это как мериться производительностью "hello world". P>Ну вот, снова не тот бенчмарк. О чем речь. Зачем тогда просишь "показать код" ?
Почему не тот? Тот, я не спорю. Хороший jit. Догоняет фичи jit-а явы ~20-летней давности. Я просто говорю, что это некорректно по одному бенчмарку (притом нарочно игнорируя остальные) делать громкие заявления о производительности всей системы.
P>>>Зачем? Ты все равно выкусишь то, что тебе удобно. P>>>Бенчмарков было больше одного. Из них ты ожидаемо выбрал тот, где либа и проигнорил те, что без либы. P>>>Какой смысл доказывать тебе? P>·>Ты конткест потерял. Перечитай что тут обсуждается. P>Я тебе просто пример, как ты откидываешь аргументы на любую тему. Собственно, в прошлый раз было ровно то же. Какой в этом смысл?
Ну нет аргументов, так и скажи, мол, не знал как C++ устроен. Я вот про c# ничего не знаю, и не скрываю. Что вилять-то?
P>>>Ну да, компенсируют проблемы языка. P>·>Языком компенсируют проблемы языка?! Это как? P>"используют обёртки" == компенсируют проблемы языка. Или, по твоему, обертки сами себя пишут?
Какие обёртки? IList это не обёртка, а конструкция языка. Язык сам себя оборачивает что-ли?
А вот когда ты сравниваешь производительность libregex с java, то node в этом случае просто обёртка поверх libregex. Но тебе норм это использовать как док-во что нода быстрая.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
P>>Ну вот, снова не тот бенчмарк. О чем речь. Зачем тогда просишь "показать код" ? ·>Почему не тот? Тот, я не спорю. Хороший jit. Догоняет фичи jit-а явы ~20-летней давности. Я просто говорю, что это некорректно по одному бенчмарку (притом нарочно игнорируя остальные) делать громкие заявления о производительности всей системы
Я как раз привел вообще все бенчмарки, вместе взятые, что бы всю картину показать.
P>>Я тебе просто пример, как ты откидываешь аргументы на любую тему. Собственно, в прошлый раз было ровно то же. Какой в этом смысл? ·>Ну нет аргументов, так и скажи, мол, не знал как C++ устроен. Я вот про c# ничего не знаю, и не скрываю. Что вилять-то?
А ты что, пишешь на С++? Я на нем почти 10 лет писал. В С++ есть фича такая "Implicit Type Casting", чем можно воспользоваться где угодно и как угодно. То есть, один товарищ заимплементил, а другой — напоролся. В итоге — проезд по памяти, или затерты данные, или еще что. По сути, ровно то же, что ты и показал — компилятор не подсказывает об ошибке.
P>>"используют обёртки" == компенсируют проблемы языка. Или, по твоему, обертки сами себя пишут? ·>Какие обёртки? IList это не обёртка, а конструкция языка. Язык сам себя оборачивает что-ли?
Это ж твои слова "поэтому и используют обёртки подобные IList". К слову, IList это не конструкция языка, а тип в стандартной библиотеке, которая идет с языком.
Вот те, про кого ты пишешь "используют обертки" делают это именно из за того, что язык и его стандартная библиотека кривоваты. Иначе бы никаких оберток не потребовалось.
·>А вот когда ты сравниваешь производительность libregex с java, то node в этом случае просто обёртка поверх libregex. Но тебе норм это использовать как док-во что нода быстрая.
В ноде в целом нормально использовать такие вещи. Платформа так устроена. А вот в джаве это нетипичный случай.
Крометого, это ведь не единственный пример. Есть и другие, но тебе они тож не нравятся.
Здравствуйте, Pauel, Вы писали:
Делать вам нечего столько времени тратить. Кратко
Выбираем язык на котором проще программировать команде.
Язык должен удовлетворять не только скорости разработки, но и скорости выполнения.
Ну и типизация дает не только синтаксическую проверку, но и интеллисенс.
Все остальное лирика. TS никогда не стане супер языком из-за его привязки к JS. Но в нем куча интересных решений как ограничение типов итд.
Тут кстати vdimas широко рекламировал Darts. Но вот популярность Darts была приблизительно равна TS. Но прошло лет 5 и соотношение резко изменилось
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>Ну и типизация дает не только синтаксическую проверку, но и интеллисенс.
Типизация это инструмент проектирования. Синтаксис, интелисенс, навигация — это минорные бенефиты. Со статической типизацией мы можем работать с кодом в единицах парадигмы, а не строчках кода. И можно менять код не переписывая, а трансформируя в новый вариант автоматическими инструментами, которые дают заведомо меньше ошибок.
Кроме того, статический анализ позволяет детектить гораздо бОльшее количестов ошибок.
Здравствуйте, Pauel, Вы писали:
P>>>Ну вот, снова не тот бенчмарк. О чем речь. Зачем тогда просишь "показать код" ? P>·>Почему не тот? Тот, я не спорю. Хороший jit. Догоняет фичи jit-а явы ~20-летней давности. Я просто говорю, что это некорректно по одному бенчмарку (притом нарочно игнорируя остальные) делать громкие заявления о производительности всей системы P> Я как раз привел вообще все бенчмарки, вместе взятые, что бы всю картину показать.
Ок. whatever. С моей точки зрения получилось так, что в остальных бенчмарках лишь демонстрировалась возможность вызова нативных либ, а не производительность самой системы ноды. Ну да, нативные вызовы из ноды не сильно тормозят... и? А сама система, движок ноды тормозит во многих ситуациях. И, как мне кажется, по той же причине, что там внутре js — когда работаем с голым FloatBuffer, то всё ок. А чуть шаг в сторону, и всё... приплыли.
P>>>Я тебе просто пример, как ты откидываешь аргументы на любую тему. Собственно, в прошлый раз было ровно то же. Какой в этом смысл? P>·>Ну нет аргументов, так и скажи, мол, не знал как C++ устроен. Я вот про c# ничего не знаю, и не скрываю. Что вилять-то? P>А ты что, пишешь на С++? Я на нем почти 10 лет писал. В С++ есть фича такая "Implicit Type Casting", чем можно воспользоваться где угодно и как угодно. То есть, один товарищ заимплементил, а другой — напоролся. В итоге — проезд по памяти, или затерты данные, или еще что. По сути, ровно то же, что ты и показал — компилятор не подсказывает об ошибке.
Если я правильно понял, что ты имеешь в виду, то это C-cast который тоже legacy в плюсах. Разговор же шел о касте vector<>, его кастить просто так нельзя и "Implicit Type Casting" тут никак не поможет.
P>>>"используют обёртки" == компенсируют проблемы языка. Или, по твоему, обертки сами себя пишут? P>·>Какие обёртки? IList это не обёртка, а конструкция языка. Язык сам себя оборачивает что-ли? P>Это ж твои слова "поэтому и используют обёртки подобные IList".
Это не обёртка для языка, это часть языка. Она не для компенсации проблем (каких, кстати?) языка, а для выражения высокоуровневых идей контейнеров объектов на низкоуровневой конструкции с массивами.
P>К слову, IList это не конструкция языка, а тип в стандартной библиотеке, которая идет с языком.
Ну да, и ничто не мешает написать свой тип с похожими фичами, если вдруг понадобится.
P>Вот те, про кого ты пишешь "используют обертки" делают это именно из за того, что язык и его стандартная библиотека кривоваты. Иначе бы никаких оберток не потребовалось.
Обёртка это просто реализация. Скажем, я могу Enum Set реализовать обернув int и используя битовые операции. Так и "список объектов данного типа" поверх массива.
P>·>А вот когда ты сравниваешь производительность libregex с java, то node в этом случае просто обёртка поверх libregex. Но тебе норм это использовать как док-во что нода быстрая. P>В ноде в целом нормально использовать такие вещи. Платформа так устроена. А вот в джаве это нетипичный случай.
Это плохо, не удобно. Когда платформа однородна, можно использовать те же тулзы. Я могу дебажить|профилировать|кастомизировать приложение целиком, пользуясь тем же наборов средств если всё написано одинаково. Например, Step Into из js в c++ сделать проблематично, в то время java.regex.Pattern это тот же java-код, с исходниками, всё прозрачно и однородно. Поэтому, я первую очередь предпочитаю простые библиотеки, и если уж совсем всё плохо с перформансом, то приходится брать нативное. А в ноде чуть шаг в сторону, приходится брать нативную либу.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Pauel, Вы писали:
P>Потоки и примитивы синхронизации — такого нет. Есть воркеры, куда передаём посредством структурного клонирования, т.е. задорого, или же передаём владение, если объект вида ArrayBuffer, что далеко не всегда удобно.
P>Итого — можно передавать только большие куски работы. А вот так, что бы сообща обрабатывать какие то данные — такое вряд ли.
Здравствуйте, ·, Вы писали:
P>> Я как раз привел вообще все бенчмарки, вместе взятые, что бы всю картину показать. ·>Ок. whatever. С моей точки зрения получилось так, что в остальных бенчмарках лишь демонстрировалась возможность вызова нативных либ, а не производительность самой системы ноды. Ну да, нативные вызовы из ноды не сильно тормозят... и? А сама система, движок ноды тормозит во многих ситуациях. И, как мне кажется, по той же причине, что там внутре js — когда работаем с голым FloatBuffer, то всё ок. А чуть шаг в сторону, и всё... приплыли.
Это заблуждение. Движок ноды, если не считать некоторых вещей, работает примерно с тем же перформансом, что и джава.
P>>·>Ну нет аргументов, так и скажи, мол, не знал как C++ устроен. Я вот про c# ничего не знаю, и не скрываю. Что вилять-то? P>>А ты что, пишешь на С++? Я на нем почти 10 лет писал. В С++ есть фича такая "Implicit Type Casting", чем можно воспользоваться где угодно и как угодно. То есть, один товарищ заимплементил, а другой — напоролся. В итоге — проезд по памяти, или затерты данные, или еще что. По сути, ровно то же, что ты и показал — компилятор не подсказывает об ошибке. ·>Если я правильно понял, что ты имеешь в виду, то это C-cast который тоже legacy в плюсах. Разговор же шел о касте vector<>, его кастить просто так нельзя и "Implicit Type Casting" тут никак не поможет.
c-cast это explicit, а я говорю об implicit. Понятно, что код будет другой, не 1 в 1, как в тайпскрипте.
P>>·>Какие обёртки? IList это не обёртка, а конструкция языка. Язык сам себя оборачивает что-ли? P>>Это ж твои слова "поэтому и используют обёртки подобные IList". ·>Это не обёртка для языка, это часть языка. Она не для компенсации проблем (каких, кстати?) языка, а для выражения высокоуровневых идей контейнеров объектов на низкоуровневой конструкции с массивами.
Забавно, что ты сам с собой споришь — я всего то процитировал тебе твои собственные слова.
P>>К слову, IList это не конструкция языка, а тип в стандартной библиотеке, которая идет с языком. ·>Ну да, и ничто не мешает написать свой тип с похожими фичами, если вдруг понадобится.
Именно это и создаёт проблемы.
·>Обёртка это просто реализация. Скажем, я могу Enum Set реализовать обернув int и используя битовые операции. Так и "список объектов данного типа" поверх массива.
Таким приходится заниматься именно потому, что язык хилый, и энумы в ём так себе.
P>>В ноде в целом нормально использовать такие вещи. Платформа так устроена. А вот в джаве это нетипичный случай. ·>Это плохо, не удобно. Когда платформа однородна, можно использовать те же тулзы.
Смотря для чего неудобно. Контролировать выжимание битов — неудобно. А вот писать эффективный высокоуровневый код — очень даже удобно. Например, моя реализация сериализатор для ODATA работает быстрее и джавовской, и дотнетной.
Здравствуйте, rollcoin, Вы писали:
P>>Потоки и примитивы синхронизации — такого нет. Есть воркеры, куда передаём посредством структурного клонирования, т.е. задорого, или же передаём владение, если объект вида ArrayBuffer, что далеко не всегда удобно.
P>>Итого — можно передавать только большие куски работы. А вот так, что бы сообща обрабатывать какие то данные — такое вряд ли.
R>Вот это вот что такое? https://developer.mozilla.org/ru/docs/Web/JavaScript/Reference/Global_Objects/Atomics
Интересная штука, как то прошел мимо неё. Используются вместе с SharedArrayBuffer, про который хром пишет
Uncaught ReferenceError: SharedArrayBuffer is not defined
В ноде вроде есть.
Все таки array buffer не самая удобная штука. Надо бы попробовать эту вещь.
Здравствуйте, vaa, Вы писали:
vaa>один русский лиспер както сравнил js c лиспом для браузера в плане гибкости. но слабая типизация это конечно зло.
Так JavaScript и создавался как реализация диалекта Lisp'a под названием Scheme, но с С-подобным синтаксисом. Поэтому многие идиомы JavaScript из Lisp'а. Это не только видно на глаз любому лисперу, но и официально задукоментировано в истории создания языка JavaScript.
К сожадению, в процессе реализации было добавлено несколько порций "говна и палок" в виде надуманных конструкций с неоднозначным поведением, но если относится к JavaScript'у как к одному из Lisp-подобных языков и работать с ним в именно в таком ключе, то он мгновенно становится вполне приличным языком; просто "говно и палки" нужно обходить стороной.
Здравствуйте, Aquilaware, Вы писали:
A>Так JavaScript и создавался как реализация диалекта Lisp'a под названием Scheme, но с С-подобным синтаксисом. Поэтому многие идиомы JavaScript из Lisp'а. Это не только видно на глаз любому лисперу, но и официально задукоментировано в истории создания языка JavaScript.
Пример идиом из Лиспа?
A>К сожадению, в процессе реализации было добавлено несколько порций "говна и палок" в виде надуманных конструкций с неоднозначным поведением, но если относится к JavaScript'у как к одному из Lisp-подобных языков и работать с ним в именно в таком ключе, то он мгновенно становится вполне приличным языком; просто "говно и палки" нужно обходить стороной.
Что за "говно и палки", без которых он станет Лиспом?
Здравствуйте, Ночной Смотрящий, Вы писали:
P>>Типизация это инструмент проектирования. Синтаксис, интелисенс, навигация — это минорные бенефиты.
НС>Это твое персональное мнение, а не факт.
Типичные шаги с твоей стороны:
1 это мнение, а не факт
2 покажи <доказательство, статистику, исследование рынка, монографию, нужное вписать>
3 я своим разработчикам < пеняю, не разрешаю, требую, запрещаю, нужное вписать >
4 <чучелко>
5 нахамить
6 убежать
Здравствуйте, Буравчик, Вы писали:
A>>Так JavaScript и создавался как реализация диалекта Lisp'a под названием Scheme, но с С-подобным синтаксисом. Поэтому многие идиомы JavaScript из Lisp'а. Это не только видно на глаз любому лисперу, но и официально задукоментировано в истории создания языка JavaScript.
Б>Пример идиом из Лиспа?
Здравствуйте, Ночной Смотрящий, Вы писали:
P>>Может тебе подсократить список до пункта 6 ?
НС>Твой не относящийся к делу спич не отменяет того факта, что ты пытаешься выдать свое частное мнение за непреложный факт.
Как ты видишь, патента на использования статической типизации в качестве инструмента проектирования я не предоставил, следовательно, это просто мнение, что вобщем норма — форум это место для обмена мнениями.
Не совсем ясно, с чего ты взял, что я это мнение выдаю за непреложный факт. Мне трудно понять, как ты делаешь такие логические выводы.
Поясни, пожалуйста, а то странно выходит — пару раз в год ты мне предъявляешь "это мнение, а не факт" и каждый раз я тебе сообщаю что "форум есть место для обмена мнениями"
Здравствуйте, Pauel, Вы писали:
P>·>Ок. whatever. С моей точки зрения получилось так, что в остальных бенчмарках лишь демонстрировалась возможность вызова нативных либ, а не производительность самой системы ноды. Ну да, нативные вызовы из ноды не сильно тормозят... и? А сама система, движок ноды тормозит во многих ситуациях. И, как мне кажется, по той же причине, что там внутре js — когда работаем с голым FloatBuffer, то всё ок. А чуть шаг в сторону, и всё... приплыли. P>Это заблуждение. Движок ноды, если не считать некоторых вещей, работает примерно с тем же перформансом, что и джава.
Ловко. Иными словами, надо не считать случаи, когда нода работает медленее, чтобы сделать такой вывод.
P>·>Если я правильно понял, что ты имеешь в виду, то это C-cast который тоже legacy в плюсах. Разговор же шел о касте vector<>, его кастить просто так нельзя и "Implicit Type Casting" тут никак не поможет. P>c-cast это explicit, а я говорю об implicit. Понятно, что код будет другой, не 1 в 1, как в тайпскрипте.
Код в студию.
P>>>Это ж твои слова "поэтому и используют обёртки подобные IList". P>·>Это не обёртка для языка, это часть языка. Она не для компенсации проблем (каких, кстати?) языка, а для выражения высокоуровневых идей контейнеров объектов на низкоуровневой конструкции с массивами. P>Забавно, что ты сам с собой споришь — я всего то процитировал тебе твои собственные слова.
Ты переиначил мои слова. Это не обёртка языка, а обёртка массива, низкоуровневой конструкции языка. Как какой-нибудь там UUID это обёртка над двумя long, например.
P>>>К слову, IList это не конструкция языка, а тип в стандартной библиотеке, которая идет с языком. P>·>Ну да, и ничто не мешает написать свой тип с похожими фичами, если вдруг понадобится. P>Именно это и создаёт проблемы.
Какие проблемы-то?
P>·>Обёртка это просто реализация. Скажем, я могу Enum Set реализовать обернув int и используя битовые операции. Так и "список объектов данного типа" поверх массива. P>Таким приходится заниматься именно потому, что язык хилый, и энумы в ём так себе.
Вкусовщина. А по-моему, самые удобные enum-ы, что мне встречались — их можно енумить! Ну и куча других полезных фич.
P>·>Это плохо, не удобно. Когда платформа однородна, можно использовать те же тулзы. P>Смотря для чего неудобно. Контролировать выжимание битов — неудобно. А вот писать эффективный высокоуровневый код — очень даже удобно. P>Например, моя реализация сериализатор для ODATA работает быстрее и джавовской, и дотнетной.
Либо магия, либо нативный код (например парсер json), либо не все фичи.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
P>>Это заблуждение. Движок ноды, если не считать некоторых вещей, работает примерно с тем же перформансом, что и джава. ·>Ловко. Иными словами, надо не считать случаи, когда нода работает медленее, чтобы сделать такой вывод.
Учитывать нужно всё.
P>>c-cast это explicit, а я говорю об implicit. Понятно, что код будет другой, не 1 в 1, как в тайпскрипте. ·>Код в студию.
Какой в этом смысл? Когда ты последний раз писал на С++?
P>>Забавно, что ты сам с собой споришь — я всего то процитировал тебе твои собственные слова. ·>Ты переиначил мои слова. Это не обёртка языка, а обёртка массива, низкоуровневой конструкции языка. Как какой-нибудь там UUID это обёртка над двумя long, например.
IList это никакая не обёртка — это интерфейс, они ничего оборачивть не может. Обертки создает конкретный разработчик.
P>>Именно это и создаёт проблемы. ·>Какие проблемы-то?
Те самые.
P>>Таким приходится заниматься именно потому, что язык хилый, и энумы в ём так себе. ·>Вкусовщина. А по-моему, самые удобные enum-ы, что мне встречались — их можно енумить! Ну и куча других полезных фич.
Я в курсе, всё, что не как в джаве, сразу плохое.
P>>Например, моя реализация сериализатор для ODATA работает быстрее и джавовской, и дотнетной. ·>Либо магия, либо нативный код (например парсер json), либо не все фичи.
Скажем, с питоном даже близко подобраться к джаве не выйдет, хота в ём полно нативного кода. Идея понятна?
Здравствуйте, Ночной Смотрящий, Вы писали:
P>>Не совсем ясно, с чего ты взял, что я это мнение выдаю за непреложный факт.
НС>Потому что используешь его как аргумент в споре.
Если непонятно, что такое мнение и точка зрения — попробуй не прибегая к зеркалу увидеть свою задницу или затылок. Не вышло? Такая вот у тебя точка зрения. И из неё никак не следует, что задницы или затылка у тебя нет.
Собственно, это нормально — мы то на форуме, который есть обмен мнениями.
Обменялись мнениями — Serginio мог бы и сказать "а я так не считаю", а вместо этого поставил +1. То есть, обменялись мнениями, он согласился с тем, ну например, что такое возможно.
А вот ты, очевидно, путаешь форум и выступление в суде. Тренируйся на задачке выше.
Я как раз привел вообще все бенчмарки, вместе взятые, что бы всю картину показать.
