Ответ: Древний язык БЕЙСИК
JAW сказал(а):
Basic — интерпретрующий язык, причем это принципиально интерпретатор.
Не знаю, как там в 60-х годах, но из того что я видел, Бейсик практически никогда не был «принципиальным» интерпретатором. Разве что на ZX Spectrum можно было написать PRINT VAL("5*X+SIN(PI)"), и он бы это вычислил. А что касается Microsoft Basic, там с точки зрения программиста не было никакой разницы, транслирован ли код в машинные команды или интерпретируется вживую.
Компиляторы BASIC, это псевдокомпиляторы.
Характерным в этой фразе является использование маюскулярной формы записи: BASIC. В противоположность древним версиям, современные реализации называются Basic.
То есть производительность программы на BASIC будет всегда относительно низкой.
Возьмите QuickBasic 4.0/4.5, откомпилируйте программу (без «Enable debugging», разумеется) и посмотрите, во что превращаются операции типа A = B + C. Лично смотрел — там простое сложение, даже без каких-либо проверок на переполнение.
Все тормоза — от некачественного программирования, от использования простых, но прожорливых методов. Математика всё равно выполняется в библиотеках, написанных на Си; я как-то сравнивал скорость вычислений Borland C 3.0 с использованием сопроцессоров x87 и через программную эмуляцию — получалось абсолютно одинаково.
Ещё одно разочаровывающее многих обстоятельство: то что вывод графики был медленный. Но так это потому что всё делалось через стандартные функции и без буферизации. Библиотеки
BGI в Си/Паскале работали точно с такой же скоростью и такими же мельканиями. Кто искал, тот находил специализированные пакеты, которые позволяли работать быстро и в любом режиме VESA, а не только в стандартных VGA. С таким же успехом, даже если вы сейчас в .NET начнёте рисовать на форме через обычный Graphics, то при многократной отрисовке будут заметны и тормоза, и мелькания. Надо использовать BufferedGraphics; да, это сложнее и более трудоёмко, но ненамного, а зато результат на пять баллов.
Возможность однопроходной компиляции (собственно по этой причине Borland и выбрал Pascal для Delphy).
Ага. И именно по этой причине получается полное обломинго с использованием паскалевских наработок в других языках. Нет объектного файла — нельзя и подключить в качестве библиотеки. Приходилось всё писать на низкоуровневом Си.
Да, кстати, о библиотеках. Я тут как-то пытался написать DLL на .NET, и долго не мог понять, почему ни одна «unmanaged» программа (то есть не-.NET) не видит экспортируемых функций. Видимо, из .NET можно экспортировать только в .NET, тогда как импорт из unmanaged DLL в .NET проходит успешно. Однако любая связь с «неуправляемым» кодом, как я понял, приводит к тому, что .NET-программа начинает требовать повышенного доверия: если установлены слишком жёсткие ограничения безопасности в настройках виртуальной машины, то попытка вызова некоторых функций программы может приводить к исключению (не фатальному).
Строгая типизация, позволяющая контролировать ошибки на стадии компиляции.
Если в VB.NET включить Strict type checking, то почти везде будет требоваться явное приведение типа (CType). А вообще, Бейсик всегда был типизированным языком — это вам не Java/PHP. Вдобавок, отсутствие указателей делало невозможными ошибки при манипуляции с памятью.
Возможность создания динамических типов данных.
В языке Visual Basic для этого сначала был тип Variant, теперь есть универсальный Object. Создавать можно что угодно: от массива массивов до коллекций любых объектов. Массивы строк переменной длины более не проблема; собственно, строки теперь только и могут быть переменной длины, а если нужно хранить массив байтов — на это есть тип Byte. Отличие String/Char от Byte ещё и в том, что строки теперь хранятся в Юникоде (опять-таки, непонимание этого может породить мифы о низкой производительности), и для поддержки преобразований в multibyte есть целый ряд функций.
Достаточная однозначность между языком и ассемблерным кодом (мы должны иметь возможность оптимизации).
Насколько я понимаю, .NET — это виртуальная машина, даже когда исходник на Си. Оптимизация псевдокода под конкретную аппаратную платформу производится перед запуском.
Если нужен строго нативный код — это вам прежние версии копать надо. VB, начиная с 5.0, предлагает выбор между псевдокодом, укоренившимся с VB 1.0, и нативной компиляцией, которую потом разве что дизассемблером расковырять можно.
Возможность оптимизации и паралельности.
Так ли оно действительно нужно: вставлять ассемблерный код? Не скрою, я и сам так поступал в досовские времена, но сейчас-то зачем? Уже не требуется «воевать» с железом — достаточно писать логику приложения. Даже если вы занимаетесь разработкой фильтров для Photoshop, мне как-то сомнительно, что нынче можно реально выиграть от ассемблерных вставок.
Что касается параллельности, я не в курсе. VB вроде бы поддерживает многопоточность, но никогда этим не интересовался.
Все библиотеи и объекты были написаны на боле других языках.
И что такого? Бейсик — это в первую очередь средство быстрой разработки, и свою задачу он отлично выполняет. Какая разница, из чего он сам сделан? Вот я взял топор, нарубил дров и развёл костёр — какое мне дело до того, из чего сделан топор? Лишь бы рубил. И главное, знать как им наиболее эффективно пользоваться.
Раньше, до появления Option Explicit, ходила такая шутка: пока программист на Си будет определять переменные, программист на Бейсике успеет написать текстовый редактор для написания программ на Си.