Javascript, PHP, Perl, Python, Java, C#, Basic,… (как видно все они одного семейства — интерпретаторы).
Java, C#, Visual Basic (.NET-версии) — не интерпретируемые. Для Javascript существуют JIT-компиляторы. Бред.
Требовался программист на язык “X”, купили книгу “X за 2 недели” и через 3 недели – мы уже пишем какой-то проект на “X”. А спустя несколько тысяч строк кода или после того, как база данных обросла реальными данными, проект начинает нещадно тормозить.
Не в тему. Незнание среды тут, как правило, не при чем. Люди, читавшие только «Ххх за N дней для профи», обычно натыкаются на проблему «у меня везде быдлокод и быдлоархитектура, я не знаю как мне добавить еще функционала, не сломав что-нибудь». До того, чтобы упереться в проблеммы производительности из-за интерпретации, у них дело не доходит.
Для начала давайте разберемся в классах языков программирования. Я бы их разбил на 3 группы
Эта классификация использовалась еще до моего рождения. Современные языки в эту классификацию не вписываются. Пример: куда пихать C#? Он не ассемблер, не интерпретируемый, и не относится к компилируемым в бинарный код языкам. Неоднозначная ситуация.
Классификация языков вообще дело неоднозначное, выше в комментариях приводились примеры.
Если вы умеете программировать на ассемблере, значит, вы знаете все нюансы работы железа
Нет. Из знания ассемблера не вытекает знание тонкостей работы процессора. Для этого нужно знать, как работает кэш, конвейер, что такое суперскалярность, в чем разница между скалярной и векторной обработкой, что такое аппаратная многопоточность… Список, разумеется, далеко не полный.
Интерпретаторы — эти языки представляют собой высшую ступень эволюции: Javascript, PHP, Perl, Python, Java, C#, Basic…
Интерпретатор — вообще не язык, это программа. Интерпретация же уже не является вершиной эволюции, выше нее, как минимум, JIT-компиляция. Список языков здесь тоже неверен.
Если под Linux есть функция “Z”, а под Windows ее нет, то вам придётся либо обойтись без нее, либо ваша программа будет работать только под Linux (например, функции работы с файловой системой).
Интересно, как же люди пишут кроссплатформенные приложения (например, игры) под разные системы?
Поэтому очевидно, что слухи о Java, которая работает быстрее C++, заметно преувеличены. И это останется так, пока процессоры не научатся понимать байт-код Java.
Такие процессоры, вообще-то, существуют.
А вот в интерпретаторах слепое погружение в сторонние абстрактные функции пагубно.
Предлагаете не использовать сторонние библиотеки, а все писать самостоятельно? Удачи.
В интерпретируемых языках работа со строками стала настолько прозрачной, что тот факт, что это одни из самых ресурсо-затратных операций, абсолютно не очевиден.
Про работу со строками были комментарии выше. Отмечу лишь, что из известных мне языков ни один не использует UTF-8 в качестве внутреннего представления строк.
Вывод: автор вообще не понимает, о чем пишет. А учитывая, что статья, как утверждает автор, рассчитана на начинающих программистов — она вообще вредна.
Java, C#, Visual Basic (.NET-версии) — не интерпретируемые. Для Javascript существуют JIT-компиляторы. Бред.
Не в тему. Незнание среды тут, как правило, не при чем. Люди, читавшие только «Ххх за N дней для профи», обычно натыкаются на проблему «у меня везде быдлокод и быдлоархитектура, я не знаю как мне добавить еще функционала, не сломав что-нибудь». До того, чтобы упереться в проблеммы производительности из-за интерпретации, у них дело не доходит.
Эта классификация использовалась еще до моего рождения. Современные языки в эту классификацию не вписываются. Пример: куда пихать C#? Он не ассемблер, не интерпретируемый, и не относится к компилируемым в бинарный код языкам. Неоднозначная ситуация.
Классификация языков вообще дело неоднозначное, выше в комментариях приводились примеры.
Нет. Из знания ассемблера не вытекает знание тонкостей работы процессора. Для этого нужно знать, как работает кэш, конвейер, что такое суперскалярность, в чем разница между скалярной и векторной обработкой, что такое аппаратная многопоточность… Список, разумеется, далеко не полный.
Интерпретатор — вообще не язык, это программа. Интерпретация же уже не является вершиной эволюции, выше нее, как минимум, JIT-компиляция. Список языков здесь тоже неверен.
Интересно, как же люди пишут кроссплатформенные приложения (например, игры) под разные системы?
Такие процессоры, вообще-то, существуют.
Предлагаете не использовать сторонние библиотеки, а все писать самостоятельно? Удачи.
Про работу со строками были комментарии выше. Отмечу лишь, что из известных мне языков ни один не использует UTF-8 в качестве внутреннего представления строк.
Вывод: автор вообще не понимает, о чем пишет. А учитывая, что статья, как утверждает автор, рассчитана на начинающих программистов — она вообще вредна.