Редактирование: Языки программирования, 05 лекция (от 19 сентября)
Материал из eSyr's wiki.
Внимание: Вы не представились системе. Ваш IP-адрес будет записан в историю изменений этой страницы.
Правка может быть отменена. Пожалуйста, просмотрите сравнение версий, чтобы убедиться, что это именно те изменения, которые вас интересуют, и нажмите «Записать страницу», чтобы изменения вступили в силу.
Текущая версия | Ваш текст | ||
Строка 24: | Строка 24: | ||
Понятие виртуальной машины оказалось не чисто теоретическим понятием. Сейчас понятие ВМ является часто употребляемым и не столь ясным. Идея реализовать в железе ВМ было довольно частой, особенно в 60–70 годы. | Понятие виртуальной машины оказалось не чисто теоретическим понятием. Сейчас понятие ВМ является часто употребляемым и не столь ясным. Идея реализовать в железе ВМ было довольно частой, особенно в 60–70 годы. | ||
- | *SYMBOL (Европа и Америка) | + | *SYMBOL (Европа и Америка) для, которой языком был '''Алгол 60''' (не являлась чистой, так как некоторые конструкции языка не были реализованы). |
*Burroughs работал на расширенном варианте '''Алгол 60''' со стеком и был чистой ВМ | *Burroughs работал на расширенном варианте '''Алгол 60''' со стеком и был чистой ВМ | ||
- | *в СССР для машин Мир–1, 2, 3 единственным языком был '''[[Аналитик]]''' — русифицированный и расширенный вариант Алгол 60, например в Аналитике были | + | *в СССР для машин Мир–1, 2, 3 единственным языком был '''[[Аналитик]]''' — русифицированный и расширенный вариант Алгол 60, например в Аналитике были опреации для символьного дифференцирования и интегрирования. Но в последствии развитие собственных машин было убито и СССР перешло на копирование чужих платформ.</p> |
*В 70-е годы получили распространение '''[[LISP]]-ВМ''' (LISP-<span lang="en-US" xml:lang="en-US">machines</span>). Аппаратная реализация была нужна для увеличения быстродействия. | *В 70-е годы получили распространение '''[[LISP]]-ВМ''' (LISP-<span lang="en-US" xml:lang="en-US">machines</span>). Аппаратная реализация была нужна для увеличения быстродействия. | ||
- | Сейчас | + | Сейчас с точки зрения количества различных архитектур сейчас их не очень много. И аппаратная реализация выглядит анахронизмом, так как реализация эта дорогая и, что еще хуже - не гибкая, так как языки сложны и отсутствует универсальный язык. Кроме того, в языке имеются недостатки, эти недостатки распространяются на архитектуру. Сейчас же языки ориентируются на архитектуру и базис очень и очень примитивен. |
===Понятие ВМ в том виде, в котором оно сформировалось=== | ===Понятие ВМ в том виде, в котором оно сформировалось=== | ||
- | + | Стандартным вариантом языка <span lang="en-US" xml:lang="en-US">[[Smalltalk]]</span> есть реализация в виде байт-кода. Была попытка аппаратной реализации этой ВМ в виде Катаны (так и не была реализована), но была программная реализация. Понятие ВМ — JVM — [[Java]] <span lang="en-US" xml:lang="en-US">Virtual</span> <span lang="en-US" xml:lang="en-US">Machine.</span>Sun стандартизовала язык Java, байт-код и набор системных вызовов = Java RunTime. Любой интерпретатор - и есть JVM. Понятие ВМ оказалось достаточно мощным и гибким. Понятно, за счёт чего обеспечивается гибкость. За счёт того, что мы не зависим от реализации. Программы, удовлетворяющие стандарту <span lang="en-US" xml:lang="en-US">Pure</span> Java, действительно переносимы. | |
+ | |||
+ | Чем мы платим? '''Производительностью'''. Например, <span lang="en-US" xml:lang="en-US">Lotus</span> <span lang="en-US" xml:lang="en-US">Notes</span>, написанная на Java, сильно тормозит. Как только речь идёт о нетривиальных приложениях, сказываются проблемы с производительностью. Спор о эффективности-неэффективности ведётся с [[1950-е|50-х]] годов. | ||
+ | Каждые 10 лет говорят, что через 10 лет компьютеры будут так быстры, что ничего уже не будет тормозить. | ||
+ | Действиетльно, сейчас эффективности уделяется меньшее внимание, о чём говорит распространение скриптовых языков — [[PHP]], <span lang="en-US" xml:lang="en-US">[[Perl]]</span>, [[JSP]], [[ASP]], они используются на стороне сервера. Но они остаются достаточно специализированными, они занимаются обработкой и генерацией текста, и с точки зрения программирования это достаточно узкая область, а Java претендовала на роль универсального языка, и роль эффективности тут больше. | ||
+ | |||
+ | .NET <span lang="en-US" xml:lang="en-US">Framework</span> ещё одна попытка, где стандартизируется только окружение, а не байт-код. ЯП.NET — MIL — JIT компиляция. Это несколько более эффективно. То есть стандартизован некий виртуальный язык. Одно время говорили, что вместо WinAPI будут использовать защищённые вызовы .NET, но это нескоро, так как как только начинаешь писать что-то хитрое, сразу надо вспоминать, как вызывать WinAPI. | ||
+ | |||
+ | |||
- | Популярна ВМ для языка Java — JVM (Java <span lang="en-US" xml:lang="en-US">Virtual</span> <span lang="en-US" xml:lang="en-US">Machine).</span> Sun стандартизовала язык Java, байт-код и набор системных вызовов. Любой интерпретатор байт-кода (например, JRT — Java RunTime) есть конкретное воплощение JVM. | ||
- | Понятие ВМ оказалось достаточно мощным и гибким. Понятно, за счёт чего обеспечивается гибкость. За счёт того, что мы не зависим от реализации. Например, программы, удовлетворяющие стандарту "<span lang="en-US" xml:lang="en-US">Pure</span> Java", действительно переносимы. | ||
- | Чем мы платим? '''Производительностью'''. Например, <span lang="en-US" xml:lang="en-US">Lotus</span> <span lang="en-US" xml:lang="en-US">Notes</span>, написанная на Java, сильно тормозит. Как только речь идёт о нетривиальных приложениях, сказываются проблемы с производительностью. Спор об эффективности-неэффективности ведётся с [[1950-е|50-х]] годов. | ||
- | Каждые 10 лет говорят, что через 10 лет компьютеры будут так быстры, что ничего уже не будет тормозить. | ||
- | Действительно, сейчас эффективности уделяется меньшее внимание, о чём говорит распространение скриптовых языков — [[PHP]], <span lang="en-US" xml:lang="en-US">[[Perl]]</span>, [[JSP]], [[ASP]], [[Python]], [[Ruby]]. Они используются на стороне сервера, но остаются достаточно специализированными, занимаются обработкой и генерацией текста, и, с точки зрения программирования, это достаточно узкая область, а Java претендовала на роль универсального языка, и роль эффективности тут больше. | ||
- | .NET <span lang="en-US" xml:lang="en-US">Framework</span> — ещё одна попытка, где стандартизируется только окружение, а не байт-код. ЯП .NET — MIL — компилируется just-in-time (JIT). Это несколько более эффективно. То есть, стандартизован некий виртуальный язык. Одно время говорили, что вместо WinAPI будут использовать защищённые вызовы .NET, но это нескоро, так как как только начинаешь писать что-то хитрое, сразу надо вспоминать, как вызывать WinAPI. | ||
=Часть 1. Основные понятия традиционных процедурных ЯП= | =Часть 1. Основные понятия традиционных процедурных ЯП= |