А почему вы смешиваете два не связанных механизма? Переключение состояний пиров удобно делать именно на автоматах
Протокол TCP подразумевает наличие неограниченого числа одновременных соединений к одному серверу (до 260 млрд, но это не важно). Например, listen и closed не являются состоянием пэра — это состояние сокета. Syn-received и Syn-received можно назвать созданием автомата, но никак не переключением, причем, автомат на сервере отличается от автомата на клиенте. «Timer expiration» — это уничтожение автоматов. Да, где-то здесь можно увидеть автоматы, хоть в реальности никто на автоматах и не реализует эти фичи. Другое дело — когда у кого-то возникает непреодолимое желание увидеть конечный автомат во всем протоколе TCP.
Можно поподробнее, что за полновесные регулярки perl? А то не знаю, как загуглить. А если ссылку дадите, буду вообще вдвойне благодарен.
Вот пример нерегулярных регулярных выражений perl:
(\w*)\s\1
\((a*|(?R))*\)
Это обратная ссылка и рекурсия соответственно, для их выполнения нужно неограниченое состояние. Какого-то фундаментального труда я не видел по этой теме — вот кратенькая статья есть, например: https://wiki.c2.com/?RegularExpressionsArent
А что, в любой игре, любой NPC-моб или бот обязан быть неотличим от игрока?
Если вы видите в игре персонажа, который упорно идёт в стену — вот это конечный автомат. Если нужно получить минимальное реагирование на более чем один раздражитель — конечный автомат отправляется на свалку.
Если нам требуется детерминированное поведение босса, чтобы дать игрокам возможность разработать против него тактику, то используйте автомат
Ну да, по сути у нас получается анимация вместо персонажа. Как я и писал — только очень тупой ИИ можно реализовать таким образом.
Если требуется хитрый обучаемый ИИ с непредсказуемыми действиями, используйте что-то другое, хоть нейросети
Нейросети очень перехайпованы — они не настолько хороши, насколько про них говорят. Грамотно спроектированный алгоритм поведения персонажа переплюнет любую нейронную сеть. В том же OpenAI приходится огромную работу выполнять вручную, чтобы персонажи перестали быть тупыми предсказуемыми мешками, которые могут побеждать исключительно за счет мгновенной реакции на события во всём игровом мире.
У нумбы как таковой (конструкции языка) фич вполне достаточно (ну, кроме классов)
Ну представьте, если я скажу «я сделал язык, который почти Си, только указатели не поддерживаются» — мне же засмеют. А почему-то питон без классов никого не смущает.
Но в любом случае в 2019 году писать про оптимизацию питона и говорить, что pypy – единственная успешная библиотека по его оптимизации это по меньшей мере странно
У PyPy нет конкурентов. Никто не может сравнимо быстро исполнять питон.
numba закрывает большую часть проблем, которые вы здесь обозначили (в частности, удобство тестирования, оптимизации и параллельного выполнения кода).
В Numba параллелизация еще более ограничена, чем классы.
Если вы любого человека, пишущего на питоне, считаете макакой, зачем вы вообще за него взялись? Или вы вообще всех программистов считаете макаками, и себя в том числе?
Можно и так сказать. Меня не особо волнует, кто там макака, а кто — нет.
Ближайшие лет 20, точно, для 90% задач, железо дешевле чем грамотный человек
Да. 90% задач дешевле выполнять без человека. Часто люди придумывают себе проблемы, которые вообще не нужно было решать. И именно наличие достаточно дешевых кодеров дает возможность попытаться решить задачу человеческими руками. У меня есть знакомый из Москвы, который для Рено в Экселе делает расчеты по экономике/бухгалтерии. Какой 1С, о чем вы?
Хорошо, а какое отношение это всё имеет к монадам?
—
диспетчеризацию по типу возвращаемого значения (монады-монадки)
Основной механизм в хаскеле для выбора конкретных «функций для реализации последовательного выполнения» (монадических функций) — это тип возвращаемого значения на каждом шаге. То есть, все функции в рамках одной монады должны иметь один и тот же тип-контейнер — благо, этот тип автоматически подставляется там, где не задан жестко.
Страшны не столько сами монады, сколько этот механизм выбора конкретной функции по типу возвращаемого значения, который заставляет всегда делать приведение к типу монады в рамках единого конвеера. И в итоге программисту приходится сильно прогибаться для выполнения банальных операций, вроде «выполни действие 1, потом выполни действие 2, потом выполни действие 3», потому что работа в монадах отличается от обычных вызовов функций, и программист должен помнить «вот здесь я в монаде, а тут — нет» — и этот ком растет с ростом сложности приложения, потому что одни монады-контейнеры накладываются на другие. Поэтому, к слову, нет ни одного крупного проекта, написанного на хаскеле — где-то в районе десятков тысяч строк сложность становится неподъемной для хомо сапиенс.
Какой COBOL? Как красиво выйти из двух циклов в C, C++, C#, Objective-C, Pascal, Delphi, VB, VB.NET без goto? Да и Python, чего же там (прежде чем вы начнёте придираться к словам, raise-except == goto)
Return. Всегда так делаю. Очень удобно делать со вложенными функциями. И да, выхода из вложеного блока не хватает, не спорю.
Очень универсально и портабельно.
__cleanup__ поддерживается GCC и Clang. Ежели хотя бы 20 лет назад это сделали, то вопрос о портируемости нынче бы не стоял. У C++, например, есть огромные проблемы с портируемостью, но никто не жалуется почему-то.
Мы уже поняли, что все языки неправильные. Тем не менее, на них надо писать сейчас, а не в будущем в ваших фантазиях.
Мне сейчас не надо. Кому надо — пусть пишет.
Так говорят те, кто не умеет им пользоваться. "Что, можно не пробелами выравнивать?" "Что, можно стили настраивать?"
Вот именно это я и имел в виду. Когда пользователь создает форматирование на стилях, якорях, и явных разрывах строк, то внезапно от WYSIWYG ничего не остается, и возникает вопрос «а зачем нам тогда MS Word?». MS Word был создан для ровно противоположной задачи: чтобы пользователь никогда не пользовался стилями, якорями, разрывами строк — именно так создают документы большинство.
Да, у ворда есть проблемы, но все альтернативы ещё хуже для большинства ставящихся перед вордом задач
Скорее, ситуация выглядит как «все альтернативные решения вымерли». Хотя, LaTeX еще вполне жив и не планирует умирать, хоть и поживает не очень.
Tuple как состоял из одного массива, так и состоит. Этот массив всё тот же. Его состав изменился, но массив всё тот же.
У list тоже массив. Тоже один. Просто сделан через хранение указателя на массив в объекте, а не хранением самого массива в объекте. как в кортеже.
вы просто не хотите принимать того факта, что вы чего-то не поняли и просто пришли "со своим уставом в чужой монастырь"
Я просто не хочу принимать того факта, что питон плохо спроектирован и с этим ничего нельзя сделать. Я постоянно пытаюсь придумать, что можно сделать.
Если в C++ классе объявить protected объект, то, насколько мне известно, в его инстансе можно вызывать любые public-методы из этого объекта, которые могут изменить внутренний состав. Это тоже плохо спроектированный язык получается по вашей логике.
C++ — это квитнэссенция худших решений. Питон неплохо смотрится на этом фоне. По этой причине программирование на C++ сводится к тому, чтобы избежать 10 проблемных фич и использовать одну удачную. Я много лет назад взял за правило не использовать модификаторов доступа строже чем public. За эти годы я не могу вспомнить ни одной проблемы, которая бы после этого у меня возникла из-за того, что какой-то другой программист обратился к структурам, которые ему не стоит трогать — обычно просто проект переставал компилироваться и сразу указывал на проблемное место.
Есть хорошая штука — __slots__, которая определяет, что новые атрибуты не должны появляться внезапно
Очень странная интерпретация, которая отличается от официальной документации.
Кортеж поддерживает иммутабельность ссылок, а не значений. Это сильно облегченная версия массива для хранения и передачи последовательности элементов, а вовсе не наоборот, как ошибочно написано в статье
Если вам нужны иммутабельные элементы в контейнере, используйте для этого иммутабельные значения
Программисту не нужны неизменяемые значения — он хочет иметь возможность их менять. Может быть, он и не будет ею пользоваться, но он хочет ее иметь. Программист обычно не хочет работать со ссылками — его интересуют только значения. То есть, он пишет «config.db_cache.enabled = False», потом пишет «config.app_cache.enabled = True», и ожидает, что после этого «config.db_cache.enabled == False and config.app_cache.enabled == True», но с таким же успехом он может получить в результате «config.db_cache.enabled == True and config.app_cache.enabled == True», потому что где-то неявно связались config.db_cache и config.app_cache. Например:
Там же вебсокеты, поэтому они не просто висят, а шлют туда-сюда хендшейки, то есть, нагружают процессор (не сильно, конечно, но все же)
Handshake — это процедура инициализации соединения. Поддерживается в живом состоянии соединение при помощи keep-alive механизма TCP, то есть, на уровне ядра ОС.
Есть целый ряд задач, в которых эрланг — не лучший выбор (тяжелая арифметика, например), ну так — сюрприз — там и C до сих пор проигрывает фортрану
Benchmarking game мало затрагивает тяжелую арифметику. Советую почитать описание тестов.
Многие сетевые протоколы удобно делать на конечных автоматах.
BGP
DHCP-Server
TCP
Да и вообще любые протоколы, которые переключаются между состояниями (типа ESTABLISHED, LISTENING, HANDSHAKING), очень удобно делать на автоматах
Сетевой протокол было бы удобно описывать описывать автоматом, если бы в нем только менялись режимы, но не передавались никакие данные. Неограниченное разобразие возможных данных и различных сценариев приводят к тому, что сетевые алгоритмы делают на бесконечных автоматах, читай «машина тьюринга». Взять банальный IP: этот протокол не ограничивает кол-во взаимодействующих узлов, для которых нужно хранить взаимосвязь MAC-IP адресов. Таким образом, алгоритму нужно бесконечное состояние, потому IP в общем случае невозможно реализовать на конечном автомате. Отсюда проистекает невозможность реализации TCP/IP на конечном автомате. По ссылке http://www.tcpipguide.com/free/t_TCPOperationalOverviewandtheTCPFiniteStateMachineF-2.htm
описана воображаемая машина, которая ничего не передает по сети, а только переключает состояния единственного соединения.
Регулярные выражения под капотом имеют автомат, да и вообще лексеры и парсеры делают на конечных автоматах
C/C++ в общем случае невозможно распарсить на конечном автомате. По какой-то такой причине, например, yacc использует стэковую машину, являющуюся бесконечным автоматом, а последняя реализована на конечном автомате + стэк.
Полновесные регулярки perl способны разбирать нерегулярные языки и не могут быть реализованы на конечном автомате. Если ограничить эти регулярные выражения до разбора регулярных языков, то можно ограничиться конечным автоматом.
В геймдев-анимации автоматами описывают переходы между состояниями «юнит бежит», «юнит в прыжке», «юнит танцует»
Да, отдельные примитивы из системы можно назвать конечными автоматами.
Так же в геймдеве можно описывать логику ИИ с помощью автоматов
Только очень тупой ИИ можно реализовать на конечных автоматах.
Ну что ж, тогда мне, наверное, придется придумывать выход. Выход начнется с примера:
>>> a = ([1, 2], )
>>> a[0].append(3)
>>> a
([1, 2, 3],)
А тут изменилось. Всё это — просто следствие плохого проектирования языка, нецелостность реализации. Здесь у нас в реализации можно менять значение, а здесь — нельзя. Tuple — вроде неизменяемое значение, но одновременно изменяемое. По хорошему, нужно было либо запрещать хранить в кортеже изменяемые значения, либо делать копии. Первое не прокатывает, потому что смотри выше: «следствие плохого проектирования языка» — кортежи используются для передачи аргументов в функции и аргументы должны быть изменяемы, потому что как-то же нужно передавать ссылки на объекты в функции, когда нет деления на ссылки и значения. Но если котрежи, как отдельные типы данных, опасны в применении, то почему они остались? Смотри выше: «следствие плохого проектирования языка». На языке Гвидо это называет «питоничность», и формально записано в виде стихов про «будет у тебя счастье, будет у тебя и горе, будешь ты бедный, но и будет у тебя много денег».
Очень часто, решить быстро, важнее, чем решить красиво. Самый простой маркер — это решение нужно всего один раз
Ну тогда кодер и вовсе не нужен. Я все-таки пытался намекнуть куда-то в сторону technical debt, которую нынче принято наращивать до небес в свете удешевления железа.
В статье упоминалась типизация через типажи/traits, в стиле утиной типизации. Это совсем не похоже на классы в C++.
Проблема классов в Numba заключается в том, что nopython режим не умеет взаимодействовать с каноничными классами питона, на которых много чего в питоне написано и с которыми привыкли работать макаки. Я не исключаю, что в каком-то будущем Numba доработают, сделают конфеткой, но пока что сыро, очень сыро. Как я писал «либо быстро, либо питон».
Они меряют число одновременных (simultaneous) подключений, которые сервер обслуживает. Одна машина (довольно крутая, но одна) обслуживает 2М соединений
«Производительность устройства — величина действия устройства, то есть отношение количества произведённой работы (выпущенного продукта) ко времени их выполнения (выпуска)»
«Вычислительная мощность компьютера (производительность компьютера) — это количественная характеристика скорости выполнения определённых операций на компьютере»
Число одновременных подключений не является мерой производительности.
Если вам классы CPython так не нравятся, может, это и к лучшему?
Да, к лучшему. Но изначальная цель была — сохранение совместимости с имеющимся наследием. Если отбросить это условие, то и Cython убог, и GDScript убог, и Numba бедна фичами.
Да ну? А если переходы условные, зависимые от внешнего мира? Почему вы все время пытаетесь ваши неверные домыслы выдать за истину в последней инстанции?
Не знаю, при чем тут это.
Я тоже не знаю. И не вижу смысла продолжать разговор загадками и отвечать вопросами.
Ага, и эти же люди будут делать
но продолжать говорить «нет, я не буду изменять неизменяемые значения».
Протокол TCP подразумевает наличие неограниченого числа одновременных соединений к одному серверу (до 260 млрд, но это не важно). Например, listen и closed не являются состоянием пэра — это состояние сокета. Syn-received и Syn-received можно назвать созданием автомата, но никак не переключением, причем, автомат на сервере отличается от автомата на клиенте. «Timer expiration» — это уничтожение автоматов. Да, где-то здесь можно увидеть автоматы, хоть в реальности никто на автоматах и не реализует эти фичи. Другое дело — когда у кого-то возникает непреодолимое желание увидеть конечный автомат во всем протоколе TCP.
Вот пример нерегулярных регулярных выражений perl:
Это обратная ссылка и рекурсия соответственно, для их выполнения нужно неограниченое состояние. Какого-то фундаментального труда я не видел по этой теме — вот кратенькая статья есть, например:
https://wiki.c2.com/?RegularExpressionsArent
Если вы видите в игре персонажа, который упорно идёт в стену — вот это конечный автомат. Если нужно получить минимальное реагирование на более чем один раздражитель — конечный автомат отправляется на свалку.
Ну да, по сути у нас получается анимация вместо персонажа. Как я и писал — только очень тупой ИИ можно реализовать таким образом.
Нейросети очень перехайпованы — они не настолько хороши, насколько про них говорят. Грамотно спроектированный алгоритм поведения персонажа переплюнет любую нейронную сеть. В том же OpenAI приходится огромную работу выполнять вручную, чтобы персонажи перестали быть тупыми предсказуемыми мешками, которые могут побеждать исключительно за счет мгновенной реакции на события во всём игровом мире.
Они привели конфиг Tsung, там нет никакого heartbeat-а.
Ну представьте, если я скажу «я сделал язык, который почти Си, только указатели не поддерживаются» — мне же засмеют. А почему-то питон без классов никого не смущает.
У PyPy нет конкурентов. Никто не может сравнимо быстро исполнять питон.
В Numba параллелизация еще более ограничена, чем классы.
Можно и так сказать. Меня не особо волнует, кто там макака, а кто — нет.
Да. 90% задач дешевле выполнять без человека. Часто люди придумывают себе проблемы, которые вообще не нужно было решать. И именно наличие достаточно дешевых кодеров дает возможность попытаться решить задачу человеческими руками. У меня есть знакомый из Москвы, который для Рено в Экселе делает расчеты по экономике/бухгалтерии. Какой 1С, о чем вы?
Элементарный пример:
https://stackoverflow.com/questions/31342012/read-and-writing-to-file-in-haskell
«resource busy (file is locked)» — типичная для хаскеля проблема, вызванная ленивостью. И это только работа с целым файлом — если пытаться читать/писать его по частями, то там проще сразу застрелиться.
—
Основной механизм в хаскеле для выбора конкретных «функций для реализации последовательного выполнения» (монадических функций) — это тип возвращаемого значения на каждом шаге. То есть, все функции в рамках одной монады должны иметь один и тот же тип-контейнер — благо, этот тип автоматически подставляется там, где не задан жестко.
Страшны не столько сами монады, сколько этот механизм выбора конкретной функции по типу возвращаемого значения, который заставляет всегда делать приведение к типу монады в рамках единого конвеера. И в итоге программисту приходится сильно прогибаться для выполнения банальных операций, вроде «выполни действие 1, потом выполни действие 2, потом выполни действие 3», потому что работа в монадах отличается от обычных вызовов функций, и программист должен помнить «вот здесь я в монаде, а тут — нет» — и этот ком растет с ростом сложности приложения, потому что одни монады-контейнеры накладываются на другие. Поэтому, к слову, нет ни одного крупного проекта, написанного на хаскеле — где-то в районе десятков тысяч строк сложность становится неподъемной для хомо сапиенс.
Return. Всегда так делаю. Очень удобно делать со вложенными функциями. И да, выхода из вложеного блока не хватает, не спорю.
__cleanup__ поддерживается GCC и Clang. Ежели хотя бы 20 лет назад это сделали, то вопрос о портируемости нынче бы не стоял. У C++, например, есть огромные проблемы с портируемостью, но никто не жалуется почему-то.
Мне сейчас не надо. Кому надо — пусть пишет.
Вот именно это я и имел в виду. Когда пользователь создает форматирование на стилях, якорях, и явных разрывах строк, то внезапно от WYSIWYG ничего не остается, и возникает вопрос «а зачем нам тогда MS Word?». MS Word был создан для ровно противоположной задачи: чтобы пользователь никогда не пользовался стилями, якорями, разрывами строк — именно так создают документы большинство.
Скорее, ситуация выглядит как «все альтернативные решения вымерли». Хотя, LaTeX еще вполне жив и не планирует умирать, хоть и поживает не очень.
У list тоже массив. Тоже один. Просто сделан через хранение указателя на массив в объекте, а не хранением самого массива в объекте. как в кортеже.
Я просто не хочу принимать того факта, что питон плохо спроектирован и с этим ничего нельзя сделать. Я постоянно пытаюсь придумать, что можно сделать.
C++ — это квитнэссенция худших решений. Питон неплохо смотрится на этом фоне. По этой причине программирование на C++ сводится к тому, чтобы избежать 10 проблемных фич и использовать одну удачную. Я много лет назад взял за правило не использовать модификаторов доступа строже чем public. За эти годы я не могу вспомнить ни одной проблемы, которая бы после этого у меня возникла из-за того, что какой-то другой программист обратился к структурам, которые ему не стоит трогать — обычно просто проект переставал компилироваться и сразу указывал на проблемное место.
Очень странная интерпретация, которая отличается от официальной документации.
Что я делаю не так? У меня новые атрибуты внезапно появились.
А вот за это спасибо, очень интересно.
Уже в 1990 году в питоне были списки и кортежи — с тех пор они не изменились.
https://github.com/python/cpython/blob/85a5fbbdfea617f6cc8fae82c9e8c2b5c424436d/Objects/tupleobject.c
https://github.com/python/cpython/blob/85a5fbbdfea617f6cc8fae82c9e8c2b5c424436d/Objects/listobject.c
Если брать ABC, который Гвидо называл главным вдохновителем, то можно увидеть, что в языке вообще нет ссылок — это язык значений:
https://homepages.cwi.nl/~steven/abc/language.html
https://homepages.cwi.nl/~steven/abc/types.html
https://homepages.cwi.nl/~steven/abc/qr.html
В то же время, в Modula-3, с которой Гвидо в то время ознакомился, ссылки были вполне явные:
http://www.opencm3.net/doc/tutorial/m3/m3_22.html#SEC22
Да, можно считать, что кортежи появились после списков. Более того, можно считать, что списки питона появились после списков ABC, потому сами являются производными, как и кортежи — ничего подобного не было в ABC.
Программисту не нужны неизменяемые значения — он хочет иметь возможность их менять. Может быть, он и не будет ею пользоваться, но он хочет ее иметь. Программист обычно не хочет работать со ссылками — его интересуют только значения. То есть, он пишет «config.db_cache.enabled = False», потом пишет «config.app_cache.enabled = True», и ожидает, что после этого «config.db_cache.enabled == False and config.app_cache.enabled == True», но с таким же успехом он может получить в результате «config.db_cache.enabled == True and config.app_cache.enabled == True», потому что где-то неявно связались config.db_cache и config.app_cache. Например:
Я понимаю, что современные продвинутые макаки научились обходить эти грабли, но это не причина для того, чтобы делать вид, будто граблей нет.
Handshake — это процедура инициализации соединения. Поддерживается в живом состоянии соединение при помощи keep-alive механизма TCP, то есть, на уровне ядра ОС.
Benchmarking game мало затрагивает тяжелую арифметику. Советую почитать описание тестов.
Сетевой протокол было бы удобно описывать описывать автоматом, если бы в нем только менялись режимы, но не передавались никакие данные. Неограниченное разобразие возможных данных и различных сценариев приводят к тому, что сетевые алгоритмы делают на бесконечных автоматах, читай «машина тьюринга». Взять банальный IP: этот протокол не ограничивает кол-во взаимодействующих узлов, для которых нужно хранить взаимосвязь MAC-IP адресов. Таким образом, алгоритму нужно бесконечное состояние, потому IP в общем случае невозможно реализовать на конечном автомате. Отсюда проистекает невозможность реализации TCP/IP на конечном автомате. По ссылке
http://www.tcpipguide.com/free/t_TCPOperationalOverviewandtheTCPFiniteStateMachineF-2.htm
описана воображаемая машина, которая ничего не передает по сети, а только переключает состояния единственного соединения.
C/C++ в общем случае невозможно распарсить на конечном автомате. По какой-то такой причине, например, yacc использует стэковую машину, являющуюся бесконечным автоматом, а последняя реализована на конечном автомате + стэк.
Полновесные регулярки perl способны разбирать нерегулярные языки и не могут быть реализованы на конечном автомате. Если ограничить эти регулярные выражения до разбора регулярных языков, то можно ограничиться конечным автоматом.
Да, отдельные примитивы из системы можно назвать конечными автоматами.
Только очень тупой ИИ можно реализовать на конечных автоматах.
Ну что ж, тогда мне, наверное, придется придумывать выход. Выход начнется с примера:
А тут изменилось. Всё это — просто следствие плохого проектирования языка, нецелостность реализации. Здесь у нас в реализации можно менять значение, а здесь — нельзя. Tuple — вроде неизменяемое значение, но одновременно изменяемое. По хорошему, нужно было либо запрещать хранить в кортеже изменяемые значения, либо делать копии. Первое не прокатывает, потому что смотри выше: «следствие плохого проектирования языка» — кортежи используются для передачи аргументов в функции и аргументы должны быть изменяемы, потому что как-то же нужно передавать ссылки на объекты в функции, когда нет деления на ссылки и значения. Но если котрежи, как отдельные типы данных, опасны в применении, то почему они остались? Смотри выше: «следствие плохого проектирования языка». На языке Гвидо это называет «питоничность», и формально записано в виде стихов про «будет у тебя счастье, будет у тебя и горе, будешь ты бедный, но и будет у тебя много денег».
Ну тогда кодер и вовсе не нужен. Я все-таки пытался намекнуть куда-то в сторону technical debt, которую нынче принято наращивать до небес в свете удешевления железа.
Однако же, меняет в «x += (1,)». Меняет в будние дни с 8 до 17, кроме четверга, в остальные дни — не меняет.
Нет, они не обслуживаются — они просто висят. Работа равна нулю.
В статье упоминалась типизация через типажи/traits, в стиле утиной типизации. Это совсем не похоже на классы в C++.
Проблема классов в Numba заключается в том, что nopython режим не умеет взаимодействовать с каноничными классами питона, на которых много чего в питоне написано и с которыми привыкли работать макаки. Я не исключаю, что в каком-то будущем Numba доработают, сделают конфеткой, но пока что сыро, очень сыро. Как я писал «либо быстро, либо питон».
«Производительность устройства — величина действия устройства, то есть отношение количества произведённой работы (выпущенного продукта) ко времени их выполнения (выпуска)»
«Вычислительная мощность компьютера (производительность компьютера) — это количественная характеристика скорости выполнения определённых операций на компьютере»
Число одновременных подключений не является мерой производительности.
Да, к лучшему. Но изначальная цель была — сохранение совместимости с имеющимся наследием. Если отбросить это условие, то и Cython убог, и GDScript убог, и Numba бедна фичами.
Я тоже не знаю. И не вижу смысла продолжать разговор загадками и отвечать вопросами.