Что именно мешало написать мегатонны разноплановых библиотек для VB, таких же по широте возможностей, как наплодили для Python, в виде COM-библиотек? Написать из можно было хоть на самом VB (как пишут библиотеки для Python-а на самом Python-е), так и на практических любых других языках (например C++). И что самое главное, использовать их в таком случае можно было бы не только из VB, но из кучи других близкородственных сред (VBA, VBScript, JScript), нейтральных (C, C++) и не очень близкородственных (PHP) сред. Благодаря тому, что технологии COM/ActiveX предлагали многим какой-то один чётко зафиксированный языко-независимый формат/механизм/протокол взаимодействия.
что продукт борланда сильнее и мощнее тогда был - неоспорим,
Как раз таки оспорим.
VLC была более обширной, целая гора элементов управления прямо из коробки. Но вот компилятор у Борланда генерировал более убогий машинный код — проверено. Линкер борландовский генерировал раздутые исполняемые файлы, не умею сливать секции импорта линкуемых объектников в один большой дескриптор импорта (с одной объединённой IAT/ILT) для каждой отдельно взятой импортируемой библиотеки).
В Delphi не было возможность стопнуться на брекпоинте и кардинально перекроить код процедуры, в которой вы остановились, убрав какие-то строки, добавив какие-то строки, поменяв какие-то строки местами, а затем продолжить выполнение с любого места. А в VB — было.
Также и работа с COM-объектами была менее удобной, если говорить о чужих COM-объектах, а написание своего COM-сервера или ActiveX-сервера тоже была более тяжёлой задачей на Delphi.
А так как она не взаимодействует непосредственно с запуском, то и не обязательно выдерживать большие нагрузки ( кроме теплового щита) А железные фермы достаточно соблюсти геометрию. Выправить для придания формы, а дальше дело техники поднять, перевернуть и вставить обратно.
Помимо того, что тут что-то неладное с русским языком, хочется сказать: правка стержневых элементов подобных ферм — дело очень сложное и неблагодарное. Прогресс давно научился делать рихтование отдельных стержневых элементов (недавно видел ЧПУ-станок, который в идеал выводит погнутый во многих местах стальной вал). Но правка фермы — дело другое. Приложение усилий к одному элементу фермы будет не только править его, но и передавать усилие и деформировать смежные элементы (тем более, что они уже потеряли устойчивость из-за деформаций). Во-вторых, для правки такой фермы нужен соответствующих размеров стапель, обладающий многократным запасом по прочности и жёсткости, чтобы самому не деформироваться в процессе правки «жертвы».
В итоге, технически целесообразнее, рациональнее дешевле и проще вырезать из стального проката новые элементы и сварить новые фермы, нежели выгибать то, что есть. Тем более, что ЧПУ лазеры/плзамы для нарезки проката давно есть, и скорее всего у космических структур типа ЦЭНКИ они уже стоят в цехах.
Так, а вот например дело дойдет до вызова pure virtual метода? Куда улетит выполнение? Что там начнет при этом выполняться — на голом железе , возможно ещё даже без инициализированной виртуальной памяти? Библиотечный stub, который выводит сообщение силами линукса?
Не боитесь и не предвидите, что когда знаний станет сколько нужно, идея писать на C++ да ещё и со становлением в зависимость от стандартной библиотеки станет совсем не привлекательной?
И то и то является пользовательскими контролами для VB
Только первое является пользовательскими контролами именно для VB. Второе является пользовательскими контролами для чего угодно на свете (если границами «белого света» считать мир Windows).
С минимумом изменений? Они сделали 64-битную версию VBA, добавили тип данных LongLong и TDC для него. Это не минимум изменений, это очень сложная переботка, учитывая что виртуальная машина целиком и полностью была написана ассемблере и помимо неё в коде EB было очень много фрагментов, пришедших ещё с 16-битной эпохи.
Или претензия в чём? Вы не смотрите на 7.1, вы смотрите по билд-номерам библиотеки EB/VBA. Или по релизам офиса, в которых попадала VBA. Насколько таким образом VBA по дате своего последнего релиза пережила VB6 (98-й год)?
Кстати, и для VB6 последний релиз был вовсе не в 98-м году, потому что выпускались многочисленные SP к нему.
Ещё в школьные годы я разработал программный продукт, одной из фич которого было наличие встроенного ЯП и IDE (у меня он назывался XCode); это не было центральной фишкой той софтины, но это был как приятный бонус, как VBA в Excel — обычно вам должно хватить штатных возможностей Excel, но если вдруг не хватает, вы можете написать что-то нестандартное. За эту работу была получена золотая медаль Intel ISEF.
VBX и OCX писать в одном месте вот так через запятую — это 5.
Это как сравнивать прерывания BIOS/DOS и WinAPI. VBX это устаревшая и узкопециализированная вещь. OCX — гениальная и крутая. Писать OCX на VB не неудобно и не сложно. Если вы собрались писать OCX на Си, это другой разговор, но в таком случае и реализовать дотнетовский элемент управления на Си будет ещё на пару порядков сложнее.
Думаю, что всё-таки внутри Microsoft всегда была предвзятость к VB как к побочному продукту существования VBA. Если смотреть на это через призму такого подхода, то для Microsoft продукт не умер, не прекратил развитие в 1998 — он продолжил развитие в виде всё новых и новых версий VBA. Просто к нему больше не прикручивали куперовский Ruby для получения побочного продукту/ответвления. А нишу этого ответвления решили закрыть дотнетом — Microsoft всегда хотела сделать свою Джаву, и вот наконец после Microsoft J++ получилась более удачная попытка.
В общем, на 85% это маркетинг, на 15% — технические сложности.
Ничего хорошо (если рассматривать его как альтернативу или замену VB). Если просто рассматривать к какой-то ещё один бейсик — ради бога, больше бейсиков богу бейсиков.
Как бы 3 этапа - разбор исходного текста - генерация промежуточного кода (p-code) - исполнение.
Это теоретизированный подход в духе «Как заработать миллиарды?»:
Придумать хитрый план
Начать работать по нему
???
Заработать миллиарды.
В случае VB/VBA промежуточных этапов и форм представления кода сильно больше, чем 3. Другой интересный факт состоит в том, что машинный код x86, когда он генерируется, не генерируется и P-кода, который при этом генерируется для работы проекта в режиме отладки (человек не произошёл от обезьяны, а человек и обезьяна происходят от общего предка)
Я не понимаю, с чем вы вспорите? Если вы предлагаете рассмотреть гипотетический вариант, где исполняемый файл содержит в себе прикладной код программы, представляемый в виде 4-битных элементов, полученных путём предварительной обработки исходного кода в момент компиляции, а также исполняющий системы, которая бежит по этой цепочке 4-битных элементов, то это не по адресу, потому что я не про такой подход говорил, что он дорогой до ресурсов. Нет смысла оспаривать то, чего я не говорил.
Я говорил, что что интерпрератор, который в момент выполнения прикладной программы будет интерпретировать исходный код прикладной программы с нуля, с сырого человеко-читаемого представления — вот он будет и медленный, и объямный по памяти.
Опять, когда вы говорите про 4-бита, про 8/12 на функцию — вы говорите о компактности представления пользовательского кода, а я говорю о [не-]компактности machinery, которая всё это делает.
С какой стати 3-й вариант медленный и унылый? Пруфы? Доводы?
Первая версия VB вышла в 1991, генерация появилась в 1997, последняя версия вышла в 1998. Он не так долго успел побыть зрелым инструментом разработки, чтобы это вошло в историю.
Я что-то не понял: когда в 1998 вышла последняя версия, возможность компилировать в Native-код убрали? Да? Нет. В 1998 ничего не изменилось. Поэтому на временной шкале если и отмечать точки переломных моментов, то 1998 год как точка явно вообще не должен был отмечен.
EXE собирал из исполняющей среды и исходников, точнее, не исходников, а байт-кода,
Обычно говорят «точнее», когда хотят уточнить и без того достаточно точное первое утверждение. Например «она была зелёного цвета, точнее фисташкового». Его странно видеть в предложениях типа «он был чёрным, точнее белым» и т.п.
Исходники и байт-код — на двух диаметрально противоположенных концах жизненного цикла программного продукта. Это руда и экскаваторы. Мука и булочки.
Если вы понимаете, что там не исходники, а байт-код, то почему называете это «интерпретируемым языком»? Точно так же работает дотнет, точно так же работает Java. Никто не говорит, что Java интерпретируемая, что C# интерпретируемый, что VB.NET интерпретируемый.
Python, PHP и современный JS тоже генерирует байт-код и выполняют его на своей виртуальной машине. Но они это делают в момент запуска и на конечном устройстве. В случае VB это было делалось один раз, при компиляции и происходило на машине разработчика.
появилась только в VB5, до этого он
Даже если бы до появления VB5 там реально вшивался бы исходный код (что not the case, как мы выяснили, исходный код не вшивался никогда), почему-то никто никогда не делает эту ремарку с указанием версии, хотя, грубо говоря, 10 лет генерации нативного машинного кода не было, после чего 20 лет эта генерация была — то есть она была бОльшую часть времени, но этого факта как будто бы не существует, зато положение дел, которое существовало меньшую часть времени, акцентируется и извращается до непомерных масштабов (готовый оптимизированный байт-код для виртуальной машины выдаётся за исходный код).
Случайно умножили на единицу, и решили, что ничего страшного в этом нет. Но забыли, что единица — мнимая.
Что именно мешало написать мегатонны разноплановых библиотек для VB, таких же по широте возможностей, как наплодили для Python, в виде COM-библиотек? Написать из можно было хоть на самом VB (как пишут библиотеки для Python-а на самом Python-е), так и на практических любых других языках (например C++). И что самое главное, использовать их в таком случае можно было бы не только из VB, но из кучи других близкородственных сред (VBA, VBScript, JScript), нейтральных (C, C++) и не очень близкородственных (PHP) сред. Благодаря тому, что технологии COM/ActiveX предлагали многим какой-то один чётко зафиксированный языко-независимый формат/механизм/протокол взаимодействия.
EXE у VB был не менее настоящим, чем у Visual C++.
Как раз таки оспорим.
VLC была более обширной, целая гора элементов управления прямо из коробки. Но вот компилятор у Борланда генерировал более убогий машинный код — проверено. Линкер борландовский генерировал раздутые исполняемые файлы, не умею сливать секции импорта линкуемых объектников в один большой дескриптор импорта (с одной объединённой IAT/ILT) для каждой отдельно взятой импортируемой библиотеки).
В Delphi не было возможность стопнуться на брекпоинте и кардинально перекроить код процедуры, в которой вы остановились, убрав какие-то строки, добавив какие-то строки, поменяв какие-то строки местами, а затем продолжить выполнение с любого места. А в VB — было.
Также и работа с COM-объектами была менее удобной, если говорить о чужих COM-объектах, а написание своего COM-сервера или ActiveX-сервера тоже была более тяжёлой задачей на Delphi.
У него же клапаны для уравнивания давления с атмосферным там, насколько я знаю.
Помимо того, что тут что-то неладное с русским языком, хочется сказать: правка стержневых элементов подобных ферм — дело очень сложное и неблагодарное. Прогресс давно научился делать рихтование отдельных стержневых элементов (недавно видел ЧПУ-станок, который в идеал выводит погнутый во многих местах стальной вал). Но правка фермы — дело другое. Приложение усилий к одному элементу фермы будет не только править его, но и передавать усилие и деформировать смежные элементы (тем более, что они уже потеряли устойчивость из-за деформаций). Во-вторых, для правки такой фермы нужен соответствующих размеров стапель, обладающий многократным запасом по прочности и жёсткости, чтобы самому не деформироваться в процессе правки «жертвы».
В итоге, технически целесообразнее, рациональнее дешевле и проще вырезать из стального проката новые элементы и сварить новые фермы, нежели выгибать то, что есть. Тем более, что ЧПУ лазеры/плзамы для нарезки проката давно есть, и скорее всего у космических структур типа ЦЭНКИ они уже стоят в цехах.
Так, а вот например дело дойдет до вызова pure virtual метода? Куда улетит выполнение? Что там начнет при этом выполняться — на голом железе , возможно ещё даже без инициализированной виртуальной памяти? Библиотечный stub, который выводит сообщение силами линукса?
Не боитесь и не предвидите, что когда знаний станет сколько нужно, идея писать на C++ да ещё и со становлением в зависимость от стандартной библиотеки станет совсем не привлекательной?
Только первое является пользовательскими контролами именно для VB. Второе является пользовательскими контролами для чего угодно на свете (если границами «белого света» считать мир Windows).
С минимумом изменений? Они сделали 64-битную версию VBA, добавили тип данных LongLong и TDC для него. Это не минимум изменений, это очень сложная переботка, учитывая что виртуальная машина целиком и полностью была написана ассемблере и помимо неё в коде EB было очень много фрагментов, пришедших ещё с 16-битной эпохи.
Или претензия в чём? Вы не смотрите на 7.1, вы смотрите по билд-номерам библиотеки EB/VBA. Или по релизам офиса, в которых попадала VBA. Насколько таким образом VBA по дате своего последнего релиза пережила VB6 (98-й год)?
Кстати, и для VB6 последний релиз был вовсе не в 98-м году, потому что выпускались многочисленные SP к нему.
Сам уже могу писать такие книжки ;-)
Ещё в школьные годы я разработал программный продукт, одной из фич которого было наличие встроенного ЯП и IDE (у меня он назывался XCode); это не было центральной фишкой той софтины, но это был как приятный бонус, как VBA в Excel — обычно вам должно хватить штатных возможностей Excel, но если вдруг не хватает, вы можете написать что-то нестандартное. За эту работу была получена золотая медаль Intel ISEF.
VBX и OCX писать в одном месте вот так через запятую — это 5.
Это как сравнивать прерывания BIOS/DOS и WinAPI. VBX это устаревшая и узкопециализированная вещь. OCX — гениальная и крутая. Писать OCX на VB не неудобно и не сложно. Если вы собрались писать OCX на Си, это другой разговор, но в таком случае и реализовать дотнетовский элемент управления на Си будет ещё на пару порядков сложнее.
Думаю, что всё-таки внутри Microsoft всегда была предвзятость к VB как к побочному продукту существования VBA. Если смотреть на это через призму такого подхода, то для Microsoft продукт не умер, не прекратил развитие в 1998 — он продолжил развитие в виде всё новых и новых версий VBA. Просто к нему больше не прикручивали куперовский Ruby для получения побочного продукту/ответвления. А нишу этого ответвления решили закрыть дотнетом — Microsoft всегда хотела сделать свою Джаву, и вот наконец после Microsoft J++ получилась более удачная попытка.
В общем, на 85% это маркетинг, на 15% — технические сложности.
Ничего хорошо (если рассматривать его как альтернативу или замену VB). Если просто рассматривать к какой-то ещё один бейсик — ради бога, больше бейсиков богу бейсиков.
Это теоретизированный подход в духе «Как заработать миллиарды?»:
Придумать хитрый план
Начать работать по нему
???
Заработать миллиарды.
В случае VB/VBA промежуточных этапов и форм представления кода сильно больше, чем 3. Другой интересный факт состоит в том, что машинный код x86, когда он генерируется, не генерируется и P-кода, который при этом генерируется для работы проекта в режиме отладки (человек не произошёл от обезьяны, а человек и обезьяна происходят от общего предка)
Я не понимаю, с чем вы вспорите? Если вы предлагаете рассмотреть гипотетический вариант, где исполняемый файл содержит в себе прикладной код программы, представляемый в виде 4-битных элементов, полученных путём предварительной обработки исходного кода в момент компиляции, а также исполняющий системы, которая бежит по этой цепочке 4-битных элементов, то это не по адресу, потому что я не про такой подход говорил, что он дорогой до ресурсов. Нет смысла оспаривать то, чего я не говорил.
Я говорил, что что интерпрератор, который в момент выполнения прикладной программы будет интерпретировать исходный код прикладной программы с нуля, с сырого человеко-читаемого представления — вот он будет и медленный, и объямный по памяти.
Опять, когда вы говорите про 4-бита, про 8/12 на функцию — вы говорите о компактности представления пользовательского кода, а я говорю о [не-]компактности machinery, которая всё это делает.
Медленно и уныло — это как раз второй вариант.
С какой стати 3-й вариант медленный и унылый? Пруфы? Доводы?
Я что-то не понял: когда в 1998 вышла последняя версия, возможность компилировать в Native-код убрали? Да? Нет. В 1998 ничего не изменилось. Поэтому на временной шкале если и отмечать точки переломных моментов, то 1998 год как точка явно вообще не должен был отмечен.
QBasic вообще не делал EXE-файлы.
QuickBasic делал, и это были настоящие полноценные полноправные EXE, как показано в статье.
Не жалко занять всю имеющуюся память интерпретатором, если по изначальной задумке это единственное, чем должно быть занято ПЗУ вашего изделия.
Обычно говорят «точнее», когда хотят уточнить и без того достаточно точное первое утверждение. Например «она была зелёного цвета, точнее фисташкового». Его странно видеть в предложениях типа «он был чёрным, точнее белым» и т.п.
Исходники и байт-код — на двух диаметрально противоположенных концах жизненного цикла программного продукта. Это руда и экскаваторы. Мука и булочки.
Если вы понимаете, что там не исходники, а байт-код, то почему называете это «интерпретируемым языком»? Точно так же работает дотнет, точно так же работает Java. Никто не говорит, что Java интерпретируемая, что C# интерпретируемый, что VB.NET интерпретируемый.
Python, PHP и современный JS тоже генерирует байт-код и выполняют его на своей виртуальной машине. Но они это делают в момент запуска и на конечном устройстве. В случае VB это было делалось один раз, при компиляции и происходило на машине разработчика.
Даже если бы до появления VB5 там реально вшивался бы исходный код (что not the case, как мы выяснили, исходный код не вшивался никогда), почему-то никто никогда не делает эту ремарку с указанием версии, хотя, грубо говоря, 10 лет генерации нативного машинного кода не было, после чего 20 лет эта генерация была — то есть она была бОльшую часть времени, но этого факта как будто бы не существует, зато положение дел, которое существовало меньшую часть времени, акцентируется и извращается до непомерных масштабов (готовый оптимизированный байт-код для виртуальной машины выдаётся за исходный код).