Victor Bomberow

А как вообще определяется лучшесть и быстрость..
А если один язык посчитал быстрее, значит он лучше?

Язык - это набор грамматик для парсера; набор правил для описания последовательности действий с данными, описания данных, работы со строками и т.д.
Язык ничего считает, и сам по себе либо хорош для какого-то класса задач, либо совсем не хорош. Например, писать кросс-платформенный три в ряд на php идея так себе. Вся магия заключается в том, для чего этот язык служит ручкой управления - для игровой приставки, телевизора, виртуальной машины, веб-сервера, специального ПО или ПК.

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

Почему новички гуглят самый быстрый язык, а не самый медленный?

Это происходит потому, что знакомство с процессом программирования начинается не с C и не с изучения алгоритмов и структур данных. В результате получается, что большая часть проблем у новичков - это когда что-то работает, но медленно, а ошибка из-за отсутствия некоторых базовых для области знаний не видна. Отсюда и возникает такой вопрос, который с точки зрения терминологии некорректно сформирован.

А количество написанных строк кода при достижении одинакового результата показывает какой язык лучше?

Количество строк в решении задачи на языке А по сравнению с языком Б может позволить неточно оценить отношение цикломатических сложностей для решений. Но это имеет смысл только для языков из одной категории. Например, для ПО для работы с геоданными и картами может потребоваться встроить какой-нибудь существующий язык, либо навелосипедить DSL. К примеру, в качестве встраиваемых кандидатов можно взять lua, js, python. Если в аналитической модели большинство операций связано с операциями над множествами, то на тестовой задаче станет видно, что решения на python самые лаконичные. Если в модели много работы с данными разных типов, то возможно тут выиграет js. Если все модели данных уже предопределены, или в числодробилках задействованы распараллеливание вычислений, то скорее всего обвязка на lua даст самый лаконичный результат. Да, все дело в том, какие именно паттерны и модели изначально встроены в синтаксис языка. По факту, именно специализация языка на классе задач позволяет сделать решение лаконичным.

Но лаконичность и скорость исполнения более важны для языков с JIT компиляцией. В AoT основная ценность это производительность программы и минимальное потребление ресурсов, в C++ лаконичность в решении это результат введения чего-то хорошего в стандарт. В целом, нужно исходить от класса задач, а не просто из количества строк.

Multiprocessing и multithreading относятся к стратегии управления разделяемыми ресурсами и оптимизации простоев между задачами, а Asynchronous invocation к паттернам проектирования.

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

Всегда хочется писать однопоточный код, который компонуется в разные исполняемые файлы, которые можно запустить как отдельные процессы. Но проблема кроется на системном уровне - с точки зрения скорости исполнения работы процессором, задержки и ожидания передачи пакетов по сети или нахождения и чтения файла просто громадные. За то время, как решение одной задачи ждёт ответа базы данных, нерационально тратить время процессора на холостую работу активного ожидания, когда все что делает процесс, это по десять раз в мс спрашивает у ОС, пришел ли ответ, пришел ли ответ, пришел ли ответ... Пройдет много времени пока ОС поймет, что процесс ничего полезного не делает, и пока переключит контекст, выгрузит один процесс, загрузит другой, может прийти ответ для процесса, который его ждал. Но теперь придется ждать, пока ОС не загрузит его.
Другая проблема процессного подхода - захват ресурса. Применяя многопоточность можно экономить на том, что обращаться к системным ресурсам будет процесс, и потоки могут просто владеть ресурсом сообща, и как будет разделяться это владение решает сам разработчик. Более того, задача чтения из общей памяти более проста, если это происходит в рамках одного процесса, а межпроцессные взаимодействия всегда более тяжеловесные.

Асинхронный вызов имеет отношение к высокоуровневым языкам. При синхронном вызове метода с точки зрения вызывающего кода происходит ожидание результата метода. При асинхронном вызове вместо ожидания происходит почти сразу переход на исполнение следующих инструкций, после вызова асинхронного метода.
В рамках асинхронного вызова также могут быть объявлены фьючерсы и промисы, которые по факту разделяют по времени выделение памяти, инициализацию и присвоение возвращаемого асинхронным методом значения.

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

У Java ME есть минимальные системные требования для целевых устройств.
Взглянув на них, становится понятно, что это не для микроконтроллеров в общем случае. Конечно, встраиваемая система встраиваемой системе рознь, но вот микроконтроллеры ещё используют не только для встраиваемых систем, а прямо в железо, например, радио-приемопередающего устройства, спроектированного на работу с протоколом физического уровня. Такие контроллеры могут иметь килобайты памяти всех видов. Зачастую, такие девайсы предлагают не так много ассемблерных инструкций, чтобы имело смысл делать под них компилятор Си. В более универсальных микроконтроллерах компилятор есть, поэтому это вполне себе повод для радости.

Там, где можно развернуть JME, уже есть Linux kernel, поэтому ответ на вопрос о том, почему больше используется Си, чем Java, заключается в том, чем занимается компания, в чем у нее бизнес и какой у нее рынок. Количественно, решений, которым нужно JME просто меньше, относительно тех, в которых не нужна прослойка в виде ОС.

alex4answ, процедурный стиль использует только понятия модель памяти, типы, инструкции, программа и подпрограмма.

Вот и всё. Никаких составных типов. Концепция "состояние" в коде никак не выражается. Держите её если хотите в голове либо в комментариях.

Никаких сущностей в коде. Держите из в голове или в комментариях.

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

Но это всё уже вводится в структурном программировании.

Процедурное программирование вводит модель памяти с понятиями стек и куча. Хотите сделать функцию в процедурной парадигме - вам придется оформить её в виде подпрограммы и вызывать её из другой. Причем понятия линковки нет, вы будете делать это используя адрес в куче, а какие-то данные, типа, аргументы, будете сами на стэк ложить, каждый раз при вызове подпрограммы "функция".
Ах, да, захотите функцию для сложения двух чисел, придется сделать ctrl-c, ctrl-v и в теле подпрограммы написать сложение двух кусков данных взятых со стека. Для разности - копируете код, в теле меняете инструкции. И так для каждой функции.

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

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

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

Дело в том, что о процедурной парадигме можно говорить только ретроспективно. В основном, процедурная парадигма это классический ассемблер.

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

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

Т.е. берёте вы современный компилятор / интерпретатор любого языка, пишете решение в один файл, не используете составные типы, а только интегрированные простые (если вы выбрали язык со строгой типизацией), не используете функции, а только операторы, как закончите, смотрите на код - вы решили задачу в рамках процедурной парадигмы.

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

А вот в языке с полной поддержкой процедурной парадигмы можно делать такие подпрограммы, которые косплеят функции, но возвращают несколько "аргументов", причем пишут прямо в память. Да и в принципе, в процедурной парадигме можно делать свой ABI, нет никаких стандартов, нет правил, ничто не истинно и всё дозволено.