Комментарии 228
Basic не плохо эволюционировал в Visual Basic for Applications (VBA) который активно используется в продуктах MS Office.
C++ за десятилетия включил в себя и объекты
Что за объекты?
вроде Delphi, а потом и Ada Язык Ada был стандартизирован в 1983 году, а Delphi (как развитие Object Pascal 1985 год) появился в 1995 году. Глаз режет.
Шозанах я прочитал? От введения объектов? в C++ до появления Паскаля из ничего.
В начале 2000-ых была война между JavaScript и VBScript (visual basic script). К сожалению VBScript в ней проиграл, хотя JavaScript чрезвычайно бедный язык в плане типизации данных и поэтому сейчас он постепенно вытесняется TypeScript-ом. Можно сказать, что Microsoft взяла реванш за тот проигрыш.
А среда MS InterDev была просто потрясающей - до неё не дотягивают даже современные IDE:
серверная и клиентская логика на одном языке
событийная модель (выбираешь событие и пишешь на него обработчик) и за счет этого мгновенная навигация по коду
умный саггест (выпадающая подсказка по коду), а не просто искалка слов
полноценная и отзывчивая отладка
Динамическая типизация хороша для программы в 2 страницы, и плоха когда больше. Поэтому ничего удивительного в том, что по мере роста размера скриптов JavaScript сначала выиграл, потом проиграл.
серверная и клиентская логика на одном языке
Благодаря web assembly это доступно и сейчас, например https://dotnet.microsoft.com/en-us/apps/aspnet/web-apps/blazor
Чего из этого нет в современной Visual Studio для C#?
Я пробовал уйти с JScript на VBScript - там доступ к COM объектам выглядел удобнее. Но в нем небыло функций высшего порядка, замыканий и вроде какие-то заморочки с регулярками. В итоге не срослось.
Как насчет Qt Creator?
Насколько я помню, дело было так.
На дворе 70-е — 80-е. Драма ещё не применяется широко, срама стоит как… ох, не напоминайте…
Из относительно дешёвого — только масочные ПЗУ. Читается «прямотоком», как срама, но по простоте примерно как драма. Но к драме ещё рефреш нужен, а он сто́ит как второй проц.
…потому что проц у нас — два притопа, три прихлопа. 6502 или в лучшем случае 8080. И писать на нём нативный код — это занять какое-то невменяемое количество памяти. На одно сложение чуть ли не 50 команд надо, чтобы всё учесть да перенести. Насчёт плавающей точки помолчу, там и реально 50 будет. Если не больше.
И тут, та-дам, Бейсик! С его байт-кодом виртуальной машины, не теряющим обратной читаемости. В сраме лежит байт команды «PRINT» и байт, обозначающий номер переменной «A», вот и вся петрушка. Ну, и где-то ещё лежит таблица того, что у этой переменной имя именно «A», чтобы не терять ту самую обратную читаемость.
Плотность кода сразу выросла в разы. В крошечной сраме начало помещаться что-то реально полезное. На наши деньги это как положить фреймворк, занимающий 16 гигов памяти, в быструю флэшку и её прямо в адресное пространство отмапить, чтобы прямо оттуда код исполнялся. Причём при бюджете африканского крестьянина, которому эти 16 гигов — очень не копейка.
Производители массово взвизгнули от восторга и стали шить в рому этот васик, чтобы юзер мог «с места в карьер» кодить подбор оптимальных соотношений редуктора методом перебора или суммировать зарплаты в «Итого». Пользователи взвизгнули от восторга и стали кодить, что уж умели и могли (даже иногда игрушки, хотя они-то не сумма зарплат, там фреймрейт 0.1 фпс не очень).
Что было бы, если бы это развивалось… хмммм… ROM-Жава? О_О
ROM-Жава?
В симках, банковских картах, и прочих аппаратных токенах безопасности именно она. Спецификацию смотрел, зверь ооочень странный после обычной жавы.
Делались одно время такие компьютеры, в которых прямо в ROM сидела JAVA (самая обычная). Но оказались невостребованны.
на самом деле нет, DRAM с середины семидесятых был доступен и заметно дешевле, там первое время скорее проблемы с надёжностью были, дохли они часто, особенно советские. Для регенерации достаточно пары счётчиков и нескольких корпусов мелкой логики, а при наличии какого-никакого графического адаптера это всё в нём и так уже было, так что на цену уже особо не влияло. Появился Z80, в нём счётчики регенерации были уже встроены, что экономило слегка денег но зато изрядно места на плате, опять же надёжность, каждый лишний корпус может сдохнуть, лучше когда меньше.
ROM читалась что масочная что программируемая одинаково просто, поэтому в персональных компьютерах масочную особо и не использовали - в случае ошибок в коде её уже не обновить, отзывать продукт себе дороже.
Обьём кода на ассемблере был всегда максимально компактным - ни кто не мешал использовать библиотеки готовых подпрограмм и писать достаточно высокоуровневую логику. Я так под 80x86 в какой-то момент перешел к использованию преимущественно шитого кода прямо в ассемблере, нашел для себя удобную форму чтобы его еще и понимать потом, практически Forth VM но без форта, сразу из ассемблера. Помнится, программа цифрового осциллографа под 80286 (600Ksps через SCSI и DMA, полноценный UI и немного цифровой обработки сигналов) весила килобайт пять наверное.
А Бейсик?- да просто бесил он на самом деле в то время, за совершенно неразумное разбазаривание ресурсов машины. До сих пор для меня загадка, как так получилось что его вообобще поголовно везде ставили, прямо как мировой заговор какой-то. На самом деле к тому времени уже достаточно приличных языков существовало, тот же Паскаль компилировал в компактный шитый код и мог бы ставиться в ПЗУшки даже маленьких машинок, всяко лучше было бы
Z80 уже сильно покрепче, там уже спокойно можно драматургией заниматься :)
…но народ привык к васику, привык обмениваться относительно кросс-платформенными крестиками-ноликами и вот это вот всё. Ну, и «язык для новичков» заодно.
Что касается библиотек готовых подпрограмм — это уже разумный следующий этап, когда нам не надо упихивать весь код в единицы килобайт. Бейсик — по сути, библиотека подпрограмм для FOR/NEXT, A=B+C и прочих вещей. То есть для «подпрограмм отдельных операций».
Похоже на такой виртуальный бейсик-процессор, а его собственные «два притопа, три прихлопа» команды — на микрокод. Даже больше на это похоже, чем на последовавшие за ним нормальные человеческие «библиотеки готовых подпрограмм», среди которых впереди всех на белом коне, конечно, библиотека эмуляции сопроцессора (она же — библиотека операций с плавающей точкой), которая более-менее сохранила сходство с).
в нашем круге общения тогда нам представлялось скорее что бейсик ставится скорее как своеобразный проходной фильтр - или ты очень скоро открываешь для себя операторы PEEK и POKE, изучаешь ассемблер и начинаешь на нём писать, а к "васику" приобретаешь стойкое отвращение, но поскольку транслятор для ассемблера вам не завезли, ПЗУшка этим васиком занята, то транслировать будешь сам, в голове, а вводить уже чистыми кодами, при том для каждой правки нужно пересчитывать адреса а относительной адресации для 8080 не придумали, так что за одно еще и научишся школьную арифметику в шестнадцатеричной системе бегло в уме считать. Или, если через фильтр не прошел, то ты не программист вовсе, ничего из тебя не получится...
Думаю, это было позже компов типа «1 кб сраму, 3 кб рому» %) z80, кстати, в них тоже отметился, несмотря на счётчики рефреша…
из западных машинок существовал правда вот такой уникум: https://en.wikipedia.org/wiki/Jupiter_Ace
Но не взлетел, видимо в 82м для таких мелких было уже слишком поздно
На спектруме я именно так и сделал )) Первые программы были на бесике. Работали медленно и печально. Случайно обнаружил что тут еще есть такая штука как ассемблер. Кассеты с нормальным интерпретатором на радиорынках 90х найти не удалось, а то что было - мне не нравилось. В результате стал писать в машинных кодах.
До сих пор для меня загадка, как так получилось что его вообобще поголовно везде ставили, прямо как мировой заговор какой-то. На самом деле к тому времени уже достаточно приличных языков существовало, тот же Паскаль компилировал в компактный шитый код и мог бы ставиться в ПЗУшки даже маленьких машинок, всяко лучше было бы
Бейсик встраивали как раз потому, что это был интерпретатор, а не компилятор. С ним можно было работать в диалоговом режиме, как с командной оболочкой. А польза компилятора на компьютере, у которого нет устройств долговременного хранения информации, весьма сомнительна.
Это мантра, которая с реальностью имеет мало общего, потому что пользователю довольно без разницы как трансляция устроена под капотом, а грамотно организованый шитый код делает границу очень размытой. Лисп содержит диалоговый режим в самой основе языка, хотя многие лиспы являются компиляторами; Форт содержит диалоговый режим согласно стандарту, уже с самых ранних версий предоставляет для работы удобный экранный редактор а не этот архаичный телетайп, считается формально интерпретатором но с уникальной особенностью предоставления программисту доступа к этапу компиляции, при этом большинство реализаций генерируют шитый код по производитрельности раз в 10 быстрее бейсика. Паскали первых лет 15ти, до Борланда, практически все генерировали шитый код и могли формально считаться интерпретаторами, но Вирт был явно противником диалогового режима, поэтому его там нет. Хотя существовали машинки с Паскалем сразу в ПЗУ, но почему-то не стали популярными.
Вообще, Бейсик убог во всём, кроме маркетинга: мнимая простота для пользователя требует от интерпретатора по нескольку проверок на каждом шаге программы, что фатально убивает производительность, которой тогда и так было мягко говоря не густо. Убогий построчный диалоговый режим по типу телетайпа, морально устаревшего за несколько лет до того как широкая публика с этим языком вообще познакомилась. Бинарная несовместимость (ABI) с нэйтивным кодом, изза чего вы например не могли дописать критические секции вашей программы на ассемблере, но вызывать из них какие-то функции имеющиеся в самом бейсике, использовать его как системную библиотеку - нет, геммор с этим обычно был такой, что проще было сразу всё писать заново.
Ничего себе «мантра» — в несколько раз разница в объёме кода, при тогдашних-то «никаких» процах…
Это когда 64К стало нормой «для бедных», а проц дорос хотя бы до z80 (про 86-й с его целочисленным умножением вообще тихо помолчу, это натурально зверь-машина) — разница стала исчезать, а то и вообще получалось не в пользу этих ископаемых васиков. А даже если и сохранялась, то контроллер драмы на общем фоне уже был копеечный, сама рама тоже в цене упала, и плюс в скорости в любом случае заруливал все плюсы васика в плане компактности кода.
Память, конечно, может мне привирать, но на хвост этой эпохе я заочно успел наступить (своей машинки по нищебродству не было, но руку на пульсе пытался держать). Тогда это было «буквально вчера», как для нас сейчас — эпоха одноядерных камней.
Другое дело, что вот тут-то бы ему и закончиться быстро, решительно. А он продолжился, да ещё с этим вот:
Убогий построчный диалоговый режим по типу телетайпа, морально устаревшего за несколько лет до того как широкая публика с этим языком вообще познакомилась. Бинарная несовместимость (ABI) с нэйтивным кодом, изза чего вы например не могли дописать критические секции вашей программы на ассемблере, но вызывать из них какие-то функции имеющиеся в самом бейсике, использовать его как системную библиотеку - нет
…вот это вообще адок. Как я уже говорил раз примерно сто, самая дичь, которую сотворила IBM — на машину с DRAM и 8086-м протащила этот васик в роме. Вместо того, чтобы сделать там урезанную бесплатную копию IBM DOS (точнее, IBM OS, потому что отчекрыжить бы им следовало именно дисковые службы) и грузить с кассетника .COM-файлы, а не какашки этого убогого васика. Ну или можно сказать по-другому — предусмотреть в BIOS загрузку с кассетника .COM-файлов, потому что если от DOS отрезать букву «D», останется только крошечная пристроечка к BIOS.
Была бы нормальная домашняя машина — слоты расширения, 16К/64К базовой памяти (кроватками), потом через ISA можно расширить хоть до печально знаменитых 640, CGA с выходом NTSC (ну видно же, что пытались же!), кассетник. И бинарная совместимость с «большой» машиной на работе. Оч ок для тех, чья должность подразумевала такую машину на работе (но уже с FM-хардом и парой дисководов, то есть дороже раза в четыре), у них зарплата была соответствующая.
И это всё убил Бейсик.
Всё имеет своё начало, свой конец и свои границы применимости. В ту эпоху его место (при сохранении описанных в цитате недостатков) было уже исключительно в калькуляторах с сегментными экранами на одну строчку. Ну, а при условии, что «развивался бы вместе с сями и питоном» — таки да, в качестве библиотеки, и то, наверное, недолго.
я вот говорю, шитый код который в те времена был очень популярен в реализациях, независимо от языка и наличия диалогового режима, он давал абсолютную экономию памяти и при грамотной организации довольно небольшие накладные расходы при исполнении. Да и бейсики того времени, как минимум те что мне довелось поковырять, тоже активно как раз его использовали; там проблема была не в организации кода, проблема была в самом языке который не позволял сделать производительную виртуалку, в результате 90% хиленького CPU улетали в трубу, и их было очень жалко
А, ну то есть вот это.
шитый код который в те времена был очень популярен в реализациях, независимо от языка и наличия диалогового режима, он давал абсолютную экономию памяти и при грамотной организации довольно небольшие накладные расходы при исполнении.
Это в корне не верно!
Необходимость наличия ПЗУ с Бейсиком в-ми битных машинах, требовала чтобы это ПЗУ было подключено в соответствующую страницу памяти (как например в стандарте MSX), что в свою очередь не давало/не дает использовать это пространство для использования оперативной памяти.
Кроме того, в нулевой странице адресного пространства, требуется подключенное ПЗУ с BIOS. Как следствие: доступная память для Бейсик программ ограничена 23кб, когда эти занятые две страницы могли бы дать еще 32кб.
А к распространению и засилью Бейсика особо приложился дядя Билли, который программист был средненький, зато маркетолух гениальный, знал как публику на свои поделия подсаживать
знал как публику на свои поделия подсаживать
Ну так у него и поделия были, чего уж греха таить, сделаны были для людей, а не для компьютеров.
его поделия создавались в первую очередь для зарабатывания денег, а люди с их индивидуальными хотелками были досадным недоразумением и подлежали интенсивной дрессировке, в чем он и его компания преуспели изрядно. Те же яблоки до самого 95го года пользователя не дрессировали и никому ничего не навязывали, считали для себя 1% рынка ПК вполне достаточным, пока не пришлось идти к этому самому дяде Биллу просить денег. Бизнес - это не про людей, и даже не про хорошую технику, это про деньги, всегда и только про деньги.
его поделия создавались в первую очередь для зарабатывания денег
Вы так пишете, как будто работать за деньги - в этом есть хоть что-то негативное. Майкрософт была в 1980-е небольшой компанией, одной из многих. В гиганта выросли они благодаря тому, что их софт был удобнее и красивее аналогов. Может быть, не такие красивые архитектурно для программиста, но зато красивые в UI для тех, кто ими пользовался.
Те же яблоки до самого 95го года пользователя не дрессировали
Как будто они не хотели :) Хотели, просто не научились ещё.
Бизнес - это не про людей
Бизнес - это всегда люди, и только люди. Бизнес - это работа одних людей, которая должна понравиться другим людям.
в гиганта и монополиста они выросли еще во времена своей дос, которая была тупым и уродливым продуктом блуда между CP/M и Unix. Apple стремились делать качественно и продавать дорого, но гений Билла заключался как раз в умении продать дрянь но дешевле, убедивши покупателя что лучшего не бывает.
"Работа одних людей, которая должна понравиться другим людям" - это Вам надо к Olivetti, редкий случай кому удалось, так чтобы еще и прогореть не сразу. Или немецкий Grundig, у тех тоже получалось пока был жив создатель
в гиганта и монополиста они выросли еще во времена своей дос, которая была тупым и уродливым продуктом блуда между CP/M и Unix
Та не были они нигде монополистами тогда. По разработке - Борланд был популярнее, по офису - Лотус и тому подобное. Ну и ДОС в 1980-е была отличной системой. А с момента DOS 2 она уже на голову превосходила CP/M, и да, стянула архитектурные идеи с Unix, что вот ни разу не было недостатком.
они очень хитро стали монополистами когда продали свою первую дос IBMам, может быть в тот раз даже ненароком, но так вышло что архитектура PC вдруг очень быстро стала доминировать на рынке офисных машин, при том что сама IBM имела с этого рынка считанные проценты, остальное были клоны, а вот MS имел их сразу всех. Dos была и недо-CP/M, и недо-Unix, с каждого помаленьку но ни того ни другого не перекрывала полностью. При том что и та и другая продолжали развиваться, а там уже появились для примера санки со своим солярисом, в плане удобства UI в графике помимо яблок были уже Иксы на юниксах, в хотя-бы в текстовом режиме появился уже нортон с его окнами и удобным редактором, но MS это всё до поры было не нужно, они убеждали пользователей что дос должен быть голым, редактор исключительно построчный, консоль в системе исключительно одна, а язык скриптов убогим и вообще ни с кем не совместимым. Потом много лет убеждали что многозадачность должна быть только кооперативная, потом что сетевой стек никому не нужен, а если нужен то мы изобретём свой и тоже убогий, зато продавать будем за экстра деньги. И при всём при этом документацию будем выдавать только по частям, чтобы всякие нищеброды получали доступ ограниченно по маленьким кусочкам, и только особо аффилированные и проверенные на лояльность друзья получали её полностью...
P.S. простите, наболело видимо, уже несколько месяцев пытаюсь подписать у них драйвер а они всё мурыжат по инстанциям, как были гады так ими и остались
Потом много лет убеждали что многозадачность должна быть только кооперативная
это точно не про яблоки, которые на вытесняющую многозадачность перешли только после возвращения Стива?
они убеждали пользователей что дос должен быть голым
не нравится голый дос - есть рынок с кучей оболочек. Хочется сэкономить - учите команды
В 90е аксакалы фапали на полуось. Я не застал и ни разу не видел, но говорят винда ее копия, только не такая глючная. Правда у самих аксакалов на компах тоже винда была ) время было рнтересное
да чего такого от юникса впитала в себя дос? я нахожу в досе в разы больше идей с мейнфреймов.
да чего такого от юникса впитала в себя дос?
IOCTL, потоки ввода-вывода, файловые дескрипторы и т.д. Первая версия DOS была совсем вообще CP/Mной, там ничего подобного не было, это всё появилось в DOS 2.x, позаимствованное из юниксов.
Первая версия DOS была совсем вообще CP/Mной, там ничего подобного не было
Да, с этим я абсолютно согласен. И она то как раз заложила все родовые травмы в DOS, от которых ни DOS, ни WIndows никак не могут избавиться, не смотря на всю штукатурку вокруг них.
Так вот, у CP/M организация файловая системы была взята от мейнфреймов: диски (тома) и файлы (наборы данных). Сюда в PC DOS 2.0 смогли добавить директории, но и в мейнфремах (например, в Tandem-овских) тоже смогли. В Tandem-ах остановились на иерархии диск->директория->файл. В DOS-е, со временем, кажется, в 4-ой версии, пошли чуть дальше и сделали поддиректории внутри директорий и оставили возможность размещать файлы прямо на дисках. Да, прямо чувствуется значительное влияние UNIX-а.
Но при этом оставили:
Ограничение на длину имени файла в 8 символов (хотя казалось бы, почему бы не изменить, коль скоро ты повторяешь наработки UNIX?);
Запрещенные имена файлов (CON, PRN, AUX, NUL, COMx, LPTx) ВЕЗДЕ, а не только в /dev, /proc, или /sys;
Запрет иметь имена файлов, заканчивающиеся на точку;
Расширения у имён файлов, непосредственно влияют на то, как файл выполняется.
При этом, концепция "ВСЁ ЕСТЬ ФАЙЛ" в DOS-е не просматривается. Через файловую систему DOS-а нельзя ни посмотреть резидентные программы, ни устройства.
Диски в DOS-е 2, 3, 4, 5, 6 не монтируются в единую файловую систему, как в UNIX-ах, а всё ещё существуют раздельно, как было и остаётся на мейнфреймах.
потоки ввода-вывода
Здесь у DOS-а всё осталось на уровне мейнфреймовских пакетных файлов. До UNIX-овских потоков они не добрались.
PC DOS 2.0 смогли добавить директории,
там не просто добавили "каталоги", но и добавили перенаправление ввода/вывода "почти как в *nix
В DOS-е, со временем, кажется, в 4-ой версии, пошли чуть дальше и сделали поддиректории внутри директорий
Неправда ваша ;) Иерархическая система ( каталог/подкаталог/подкаталог) работала со второй версии. 8)
Да, прямо чувствуется значительное влияние UNIX-а.
Если вы погрузитесь в историю, то мелкомягкие тогда очень сильно топили за UNIX WAY. А DOS2 был первым шагом чтобы DOS стал Xenix (Unix) %)
Ограничение на длину имени файла в 8 символов (хотя казалось бы, почему бы не изменить, коль скоро ты повторяешь наработки UNIX?);
Ограничение это совместимость с уже наработанным ПО, поэтому формула 8+3 и дожила до Win9x с VFAT. Но там уже были совсем другие извращенные танцы. ;)
Запрещенные имена файлов (CON, PRN, AUX, NUL, COMx, LPTx) ВЕЗДЕ, а не только в /dev, /proc, или /sys;
Опять же, ограничения изза совместимости с наработанным ПО ;)
Запрет иметь имена файлов, заканчивающиеся на точку;
Без расширения файлы спокойно себе создавались и редактировались. Так что тут тоже мимо ;)
Расширения у имён файлов, непосредственно влияют на то, как файл выполняется.
В DOS есть только два типа исполняемых файлов, это com и exe
А все остальные файлы, включая bat это всего лишь файлы с данными ;)
При этом, концепция "ВСЁ ЕСТЬ ФАЙЛ" в DOS-е не просматривается.
Так этой концепции в Dos не было изначально ;)
Диски в DOS-е 2, 3, 4, 5, 6 не монтируются в единую файловую систему, как в UNIX-ах
Опять же: Из соображений совместимости с наработанным ПО ;)
Здесь у DOS-а всё осталось на уровне мейнфреймовских пакетных файлов.
Так перенаправление и потоки организовывались через временные файлы и последовательное исполнение программ (ОС то у нас ОДНОЗАДАЧНАЯ)
До UNIX-овских потоков они не добрались.
"Вам шашечки или ехать?" %)
В рамках ограничений однозадачной ОС, потоки были функциональными. Просто нужно было не забывать об ограничениях. ;)
В DOS-е, со временем, кажется, в 4-ой версии, пошли чуть дальше и сделали поддиректории внутри директорий и оставили возможность размещать файлы прямо на дисках. Да, прямо чувствуется значительное влияние UNIX-а.
Это как раз произошло со второй версии DOS, но основная суть сего изменения была отнюдь не в этот. Главных юникс-стайл изменений было два:
Единообразный ввод-вывод, "всё есть файл", будь то файл на диске, консоль, принтер, порты ввода-вывода - всё стало файлами в файловой системе, причём вы их даже нашли, но опознать не смогли :)
Доступ к файлам по дескрипторам. В CPM-ной версии использовались структуры File Control Block. Они тоже остались, для обратной совместимости, но основной способ работы с файлами теперь стал как в юниксах
Ну и да, потоки ввода-вывода.
Здесь у DOS-а всё осталось на уровне мейнфреймовских пакетных файлов. До UNIX-овских потоков они не добрались.
В DOS как минимум есть перенаправление потоков и пайпы, по меркам 1980-х это было более чем достаточно.
Давай начнем с пайпов :)
Во времена windows 2000 занесло меня на собеседование в галеру (тогда слов таких не было) , которая портировала всякое разное для Apple. И уже на курсах я понял, что оно напоминает. Windows 3.11. 1 задача подвисает - тормозит все. Документация - в том шкафчике, но вам туда рано, изучайте ide. По сравнению с windows, с нормальной многозадачностью, с общедоступной прекрасной документацией.. очень уж оно показалось убогим.
Была бы нормальная домашняя машина — слоты расширения, 16К/64К базовой памяти (кроватками)
IBM в этот рынок вот вообще не метила. IBM PC был с пелёнок профессиональной машиной, и по функционалу, и по цене. Он на момент выхода стоил в минимальном конфиге полтора килобакса, это с 16К памяти и без излишеств вроде дисковода и графики. За эти деньги можно было купить пять домашних компов в то время а-ля Commodore VIC-20/Atari 400. Бейсик там в ПЗУ был сугубо ответом на пожелания клиентов, которые к этому привыкли.
Ну как бы да, там Вася и выход на NTSC были как из другой вселенной. И если Васю ещё можно объяснить «привычками», то NTSC — это удивительный артефакт, это прямо как предвестник будущего PCjr, он же «Поиск» курильщика (в «Поиске», правда, ISA была курильщика, но в остальном это просто была наглядная демонстрация того, чего IBM могла взять на домашнем рынке буквально со старта). Могла бы, если бы не
IBM в этот рынок вот вообще не метила
Может быть, видеокарты делали люди, которых не предупредили о том, что
на момент выхода стоил в минимальном конфиге полтора килобакса, это с 16К памяти и без излишеств вроде дисковода и графики. За эти деньги можно было купить пять домашних компов в то время а-ля Commodore VIC-20/Atari 400.
…и что все усилия по подключению к телевизору будут, собственно, напрасны. Единственное объяснение.
До сих пор для меня загадка, как так получилось что его вообобще поголовно везде ставили, прямо как мировой заговор какой-то. На самом деле к тому времени уже достаточно приличных языков существовало
А много из этих приличных языков помещалось в 4-8 килобайт ПЗУ, как это делали интерпретаторы Бейсика?
В 4кб помещался полный Форт, с операционкой, дебаггером и экранным редактором, практически IDE по современным понятиям. В 8кб помещались Фокал в БК0010, тоже неплохой язык, если уж с Бейсиком сравнивать, и некоторые простые реализации Паскаля. Интерпретатор Лиспа поместился бы вполне, вместе с неплохой библиотекой, если бы кто-то этим занялся; простые интерпретаторы Лиспа делаются в несколько десятков байт кода, остальное это собственно библиотека, подобно как в Форте. Хотя для Лиспа видимо в то время не было стантарта который бы это регулировал, Лиспы обычно крутились на других машинах и для других задач; когда Чак Мур этой задачей занялся, у него собственно Форт и получился, хотя теорию он в студенчестве слушал у самого Маккарти. Другое ответвление от Лиспа, для домашних машинок и детского программиерования - язык Лого, и ведь он вполне удался?
Вот, вы сами ответили на свой же вопрос: возможные альтернативы - компактная, но мозгодробительная для новичка стековая машина Форт, недобейсик Фокал и такой же мозгодробительный Лисп. Бейсик был однозначно уместнее всего этого.
он был уместнее исключительно с точки зрения маркетинга, да и маркетинг тот ориентировался не столько на пользователей, которые дети и сами ничего не решают, сколько на тогдашних учителей и родителей с их пониманием информатики на уровне собственной молодости времен 60х, телетайп и вот это всё. А дети куда более гибки в своем восприятии нового и прекрасно бы освоились и с Лого, и с Фортом, и с Паскалем, если бы им дали такую возможность и выбор.
он был уместнее исключительно с точки зрения маркетинга
Он был уместнее с точки зрения его соответствия естественному человеческому языку и императивному мышлению.
Сравните:
10 PRINT "QUADRATIC EQUATION SOLVER: A*X^2 + B*X + C = 0"
20 INPUT "A = "; A
30 INPUT "B = "; B
40 INPUT "C = "; C
50 D = B*B - 4*A*C
60 IF D < 0 THEN PRINT "NO REAL ROOTS": END
70 IF D = 0 THEN X = -B / (2*A): PRINT "ONE ROOT: "; X: END
80 X1 = (-B + SQR(D)) / (2*A)
90 X2 = (-B - SQR(D)) / (2*A)
100 PRINT "ROOTS:"
110 PRINT "X1 = "; X1
120 PRINT "X2 = "; X2\ Quadratic equation solver in Forth
: quad ( a b c -- )
>r >r >r \ stack: ( -- ) with a b c saved in return stack
r@ r> r> \ bring c b a back: a b c
>r >r >r \ save again: want a b c in return stack
r@ r@ * 4 * \ 4*a*c
r> r> 2dup * \ b*b
swap - \ discriminant = b*b - 4*a*c
dup 0< if
drop ." No real roots" cr
rdrop rdrop rdrop exit
then
dup 0= if
0 swap - \ -b
r> 2 * / \ / (2*a)
." One root: " . cr
rdrop rdrop exit
then
sqrt \ sqrt(D)
>r \ save sqrt(D)
r> \ retrieve sqrt(D)
r> \ retrieve a
2 * \ 2*a
>r \ save denominator
r> r> \ bring sqrt(D) and b
negate \ -b
over + r@ / \ (-b + sqrt(D)) / (2*a)
." X1 = " . cr
swap - r@ / \ (-b - sqrt(D)) / (2*a)
." X2 = " . cr
rdrop
;
01.10 T "QUADRATIC EQUATION SOLVER",!
01.20 A "A=":A
01.30 A "B=":B
01.40 A "C=":C
01.50 S D = B*B - 4*A*C
01.60 I (D) 01.80,01.70,01.80
01.70 T "NO REAL ROOTS",!; GO TO 01.99
01.80 I (D) 01.90,01.90,01.95
01.90 S X = -B/(2*A)
01.91 T "ONE ROOT: ",X,!; GO TO 01.99
01.95 S X1 = (-B + SQRT(D))/(2*A)
01.96 S X2 = (-B - SQRT(D))/(2*A)
01.97 T "X1 = ",X1,!
01.98 T "X2 = ",X2,!
01.99 R
(defun quadratic (a b c)
"Solve a*x^2 + b*x + c = 0. Returns list of roots or NIL if no real roots."
(let* ((d (- (* b b) (* 4 a c)))) ; discriminant
(cond
((< d 0)
(format t "No real roots.~%")
nil)
((= d 0)
(let ((x (/ (- b) (* 2 a))))
(format t "One root: ~A~%" x)
(list x)))
(t
(let* ((sqrt-d (sqrt d))
(x1 (/ (+ (- b) sqrt-d) (* 2 a)))
(x2 (/ (- (- b) sqrt-d) (* 2 a))))
(format t "Roots: X1 = ~A X2 = ~A~%" x1 x2)
(list x1 x2))))))
Лисп красив, а Форт техничен как чистая машина Тьюринга. Попробуйте еще и Лого, а потом дайте сравнить детям с восприятием не изорудованным бейсиком :) И вообще, мы сейчас в другом времени находимся, тот же Луа родом от Паскаля на этой задаче тоже красивее будет
Лисп красив, а Форт техничен как чистая машина Тьюринга.
Они красивые для вас, потому что вы сначала научились программировать, а потом уже стали понимать красоту и ценность умственных упражнений по программированию. А что бы вы там поняли, будь вы тем самым ребёнком? Бейсик, это как раз то, что вы уже знаете со школьных пелёнок. Как вы делали вычисления в тетрадке, так вы их делаете и на экране. А с Фортом/Лиспом надо заново учиться и писать, и читать, и считать. Вы увидите это филькину грамоту лет в десять, и у вас даже желания её разбирать, скорее всего, не возникнет.
тут как раз замкнутый круг, или "ошибка выжившего" - со школьных его знают как раз потому что кто-то когда-то сильно постарался чтобы во всех школах оказался именно он, а не например Паскаль или Лого. Заслуженно или нет, вопрос вторичный, на вкус и цвет все фломастеры разные - на мой взгляд, губительно именно то что вообще один всего язык доминировал целую эпоху, не оставив детям возможности осознанного выбора. Как если бы во всех музыкальных школах преподавали только барабан, потому что детям это проще..
тут как раз замкнутый круг, или "ошибка выжившего" - со школьных его знают
Я не про знание Бейсика, я про знание математики и составления алгоритмов. На Бейсик оно перекладывается естественным образом. А на Форт или Лисп - нет. Что касается Паскаля, он лучше Бейсика, конечно же. Но увы, в природе банально не было реализации Паскаля, которую можно было бы всунуть в 8К ПЗУ, а если бы и была, она была бы сильно урезанной даже в сравнении с довольно простым Паскалем Вирта, и вряд ли получилась лучше Бейсика в своём куцем варианте.
были Паскали в ПЗУ, точно были, но я сейчас уже не найду источники, сорри, был в сети какой-то университетский сайт где архивировалась вся история Паскаля и связаных с ним машинок.. И для БК0010 вроде даже были картриджи с Паскалем, а там тоже по 8кб памяти было
И для БК0010 вроде даже были картриджи с Паскалем, а там тоже по 8кб памяти было
Компилятор Паскаля на ДВК весил 50-60 килобайт в зависимости от версии, и это только чисто компилятор, без системной библиотеки. Я не думаю, что на БК там могло существовать что-то 8-килобайтное, особенно в свете того, что подобный софт туда с ДВК и портировался, а не писался с нуля.
думаю что здесь Вы всетаки ошибаетесь, столько нaверное даже продвинутый борландовский TP не весил, наверное всетаки это с библиотекой столько. Тем более что когда Вирт его создавал такие обьёмы даже для университетских машин были немыслимым расточительством, а он стремился сделать легкодоступный язык для студенческих классов в пределах возможностей своего времени, вряд ли он стал бы включать в компилятор столько избыточной сложности
думаю что здесь Вы всетаки ошибаетесь, столько нaверное даже продвинутый борландовский TP не весил
Да, извиняюсь, соврал, 50К он весил вместе с системной библиотекой:
https://archive.pdp-11.org.ru/ukdwk_archive/dwkwebcomplekt/pascal/
Но без неё он не работает, там же всякие штуки вроде read/readln/write/writeln реализованы.
состав библиотеки можно как раз вариировать, и сходная функциональность даже для разных языков будет занимать примерно одинаково. Сам компилятор для Паскаля наверняка весил поболее чем для Бейсика, это понятно, но думаю всетаки не значительно
Сам компилятор для Паскаля наверняка весил поболее чем для Бейсика
Да я же ссылку выше дал, 26К чисто компилятор весил, и 24К системная библиотека. Ну, порезать её можно, дисковые операции там убрать, например, которых нет у 8-битных машин. Пусть 8К она будет весить только с самым необходимым - ввод-вывод на консоль и базовая математика, все равно в ПЗУ это никак не уместить.
и да, программистом я стал после того как в 11 лет на каких-то демонстрационных БК0010 случайно открыл листинг бежавшей там программы на Фокале, и вдруг загорелся в этой филькиной грамоте разобраться...
случайно открыл листинг бежавшей там программы на Фокале
Ну т.е. всё-таки на ухудшенном и упрощённом Бейсике.
так для ребёнка всё одно странно структурированная абракадабра, пара слов в комментариях и те английские, остальное всё буквы и цифры - как вот из этого игра с графикой получается? Был бы там Форт - занимался бы им первым, а так я до него добрался уже после Бейсика, когда осознанно стал искать альтернативы. Благо, техническая библиотека у нас в городе была отменная, можно было найти книги по любым языкам, от фортрана до пролога. Свой первый Форт я тогда написал уже сам, изучивши по книжке и под 8080 освоивши ассемблер, взять готовый не откуда было...
так для ребёнка всё одно странно структурированная абракадабра, пара слов в комментариях и те английские
В мире очень много детей, для которых английский язык - родной. А еще в мире очень много детей, изучающих английский как иностранный с глубокого детства. Так что проблемы в этом точно нет - для детей, в смысле.
Думаете, если русскоязычному ребенку показать код на 1С, он сразу его поймет? ;)
на Фокале принято писать операторы только одной буквой, строк там нет, поэтому человеческие слова там бывают только в комментариях, среди остальной странным образом структурированной мешанины букв и цифр. Когда знаешь язык писать на нём легко и быстро, но для тех кто его не знает это выглядит как шифр. Читаемость кода минимальная, хуже наверное только в языке M (Mumps) было, зато так интересно и загадочно :)
Профессиональный программист понимает, что программный код в дальнейшем может (и даже по прошествии нескольких лет) поддерживаться (видоизменяться и дополняться) уже другим разработчиком. Поэтому его естественное восприятие и читабельность обеспечиваются в первую очередь синтаксисом, простотой и наглядностью самого языка программирования. У Вас спор между любителем и профессионалом.
Забавно как даже в элементарном примере видно насколько Лисп зверская штука. Иного варианта кроме как написать реально работающую функцию (а не абстрактную иллюстрацию "простоты" программирования на Бейсике) и не получается. И одновременно очевидно почему мейнстримом он так и не стал (в том числе потому, что сразу надо писать реально работающие функции, а не абстрактные иллюстрации). Если бы Лиспа не существовало, его следовало бы выдумать.
Вот это было бы настоящее "Что было бы".
А по поводу стековой машины - так HP лет двадцать выпускал программируемые калькуляторы с обратной польской записью, все ими пользовались и считали это нормальным - человек довольно легко к такому адаптируется, если не устраивает сам себе психологические барьеры.
И перестали выпускать потому что.. Почему? Потому что появились нормальные калькуляторы, со скобками. В которые можно просто набрать формулу из справочника - и оно работает. Без трансляции в польскую запись.
понятное дело, отпала техническая необходимость. Я исключительно о том что тот или иной способ записи - фактор совсем не решающий; нужно было - привыкли, перестало быть нужно - снова отвыкли, а разминать мозги никогда не вредно
Ну то есть, в принципе, если бы на первых машинах «три кило рому, кило сраму, проц на полтора регистра» шили бы интерпретатор форт-машины, которая тоже позволяла бы в байт положить одну «человеческую» команду «добавь к последнему значению предыдущее и сдвинь стек» (которая для своего выполнения, особенно с плавающей точкой, требует выполнить сотню машинных), сейчас бы на месте васика был Форт, а все ругались бы на сформированные им привычки к стеку, потому что «ну куда вы все со своими детскими стеками, информатикой вы в школе травмированные, тут же предсказание ветвлений, разрушение кэша, прогрев кэша, надо память воспринимать как набор областей с адресацией по указателям, а у вас всё ваш стек в голове!»
Главное — чтобы IBM не зашила бы в ром форт вместо васика, потому что тогда ранние домашние пека убил бы форт, а не васик :-D
Может, так бы было и лучше, кто знает, кто знает… к форту хорошо прикручивается очень горячий кэш стека, несколько команд за такт можно выполнять. С рандомом это не всегда прокатывает.
Ви таки будете смеяться, но небезызвестная SUN ведь таки и ставила полноценую Forth VM во все свои спарки, вместо биоса, а драйвера в ПЗУшках на самих карточках делались исключительно в байткоде, что позволяло им работать одинаково на всех машинах, независимо от архитектуры процессора.
Только это был уже не шитый код, это был байткод; основное различие в том что для байткода каждый оператор имеет стандартизированной номер, поэтому готовым скомпилированным кодом можно обмениваться как бинарным, как сейчас для java. Шитый код имеет похожий принцип но транслируется в самой машине сразу в адреса соответствующих подпрограмм, он может даже между вызовами одной программы отличаться - это делает его по производительности заметно эффективнее байткода, но в 2-3 раза менее компактным, смотря по реализации. Что тем не менее ни в какое сравнение не идёт с полностью нативным бинарным компилятом, тратить 2-3 байта на запись высокоуроневого оператора могли себе позволить даже совсем мелкие машинки, и уж это был бы всяко более разумный компромис чем тратить только 1 байт но дополнительно 90% процессора
…единственное меня смущает — очень уж за стеком там надо следить во всех ветвлениях. Может, за давностью лет ошибусь, но есть у меня подозрение, что проги, ориентированные более на принятие решений, чем просто на последовательные вычисления, при достаточной сложности дерева решений или становятся неотлаживаемыми, или форт превращается… превращается… превращаются брюки… превращаются опять в похабный бейсик, просто написанный фортом.
Но это не точно. Давно я не брал в руки шашку шашек.
Да понятно, Форт был язык для маленьких машин, у него не было потенциала роста как в C - программисту давались эффективная среда и сильные инструменты для низкого уровня, но на более высоком мы неизбежно превращались в велосипедостроителей с квадратными колесами, переизобретая вещи которые в другом месте кто-то более опытный уже бы сделал за нас, как те же деревья, алгоритмы сортировки, разбор строк или серьёзную оптимизацию для компилятора. По принципу works for me и научиться этому было в любом случае полезно, но кто-то другой мог бы именно это сделать лучше.
Да, и как раз старшему поколению они вообще не давались. Как сейчас помню самоуверенную тётку и МК-52 :-D Хорошо, быстро хоть сдалась, поняла своё бессилие перед непривычным :)
Так что тезис про учителей и то, что детям бы Форт вполне зашёл — могу подтвердить практически.
В 8кб помещались Фокал в БК0010, тоже неплохой язык, если уж с Бейсиком сравнивать
Неплохой-то неплохой, но операций со строками в нём нет, а из графических средств - только рисование точек и прямых отрезков. Что касается Лиспа, то это язык весьма специфический. Программа на Бейсике, в отличие от него, выглядит как пошаговая инструкция на понятном английском языке.
это был как-бы сарказм, Фокал имел весьма ограниченные преимущества перед Бейсиком - порог входа еще ниже, написать небольшую программу можно было еще быстрее, тип данных только один и сразу с плавающей запятой, но за это он еще более тормозной и читаемость программ еще хуже. Изза чисел с плавающей запятой он видимо и требовал "чуть" больше места в ПЗУ чем такому языку с пятью операторам бы требовалось, всетаки по функциям там поставлялась вся тригонометрия. HP его собственно и придумал для чего-то вроде программируемых калькуляторов, писать простые программы для сложных расчетов
До сих пор для меня загадка, как так получилось что его вообобще поголовно везде ставили, прямо как мировой заговор какой-то.
Кому-то пришла в голову идея, что компьютер может быть бытовым прибором для многих, а не узкоспециализированным устройством для профессиональных программистов и программистов-аматоров. И тут обнаружилось, что нужно что-то, что снижает порог входа в программирование до почти нулевой высоты. На тот момент таким решением был BASIC, и именно этим он прекрасен. Если для вас, программиста, BASIC выглядит как недоразумение, то для не-программистов это возможность без подготовки запилить свой первый hello world, написать что-то пусть очень простое, но работающее, и либо учиться дальше, либо остаться тем гибридом пользователя и чуть-чуть программиста своего бытового компьтера - игрушки и рабочего инструмента для каких-то нехитрых задач.
А потом пришел конвейер, и похоронил шитый код.
Жалко до слез, но ничего не поделаешь.
даже иногда игрушки, хотя они-то не сумма зарплат, там фреймрейт 0.1 фпс не очень
Игрушки разные нужны, игрушки разные важны. Для какого-нибудь квеста или пошаговой стратегии (понятно, без эпических зарубов гномов с гоблинами) - почему бы и нет?
Ну, кстати, в силу пресловутого компактного кода, возможно, где-нибудь на дендях (будь там интерпретатор васика в роме самой приставки) можно было бы сделать пошаговую стратегию с достаточно сложной логикой. Шибко сложнее и умнее, чем реально было бы в память картриджа напхать нативным кодом.
Но она ооооой сколько бы над каждым ходом думала :)
Насчёт аркад — ну, наверное, можно было бы и в поэкранной аркаде сделать какую-то «сложно-умную» часть, которая васиком считается между экранами, а потом в пределах экрана работает быстрое рубилово на нативном коде. Взаимосвязь между «убил/пожалел» NPC на одном экране и «напали/не напали» на другом, например. Ну и кучу всего такого, что можно быстро подшаманить в уровне бейсиковой логикой, а потом скормить игре. Вплоть до развитого сюжета или вообще элементов RPG.
Но это прямо оооочень хороший бейсик надо разрабатывать. Чтобы прямо «три байта на две строчки».
ROM-Жава?
ещё хуже, аппаратная jvm и расширения в наборе инструкций процессора. ARM926EJ
да и не только арм, где-то у меня валялась плата с at32ap7000.
но что-то не взлетело совсем
C получился компактным по синтаксису, но при этом очень близким к машинному уровню.
С одной стороны, он имел всего около 30 ключевых слов, минимальные абстракции и практически прямую трансляцию в ассемблер.
Это не так. Программистам на С не приходилось на ежедневной основе играться регистрами, вызывать прерывания, развлекаться с математикой по разные типы чисел и так далее.
Язык C стал лидером в системном программировании и спровоцировал рост себе подобных (C++, Java, C# и т. д.)
И снова мимо - ни один из озвученных языков не разрабатывался как "подобный С". Если речь исключительно о синтаксисе, то так и пишут "С-подобный синтаксис".
Дальше не читал.
До сих пор считаю GWBASIC лучшим языком для школьников. Минимум синтаксиса, минимум порог входа - и сразу возможность сделать что-то работающее. Паскаль лучше, но для школьных кружков, для тех, кому интересно вникать, вкладываться.
Не вы один. Бедные школьники.
Я считаю для этой цели куда лучше JavaScript. В минимальном исполнении так же прост, но при этом логика у него именно современная. И если кто-то вопреки стараниям педагогов сумел увлечься, ему не придётся JS немедленно забывать, переходя к практическим задачам.
Фреймворк CT.JS можно самому скачать, запустить, и там, написав ровно 2 строчки сделать летающий по окну смайлик, который пищит, когда по нему кликаешь. А потом из меню скомпилировать в EXE и в APK ! Я думаю, это увлекает детей куда сильнее, чем возможность написать "Привет!" в чёрную консоль дос-эмулятора.
Не надо Javascript. Как Вы объясните детям, почему "1"+2 и 1+"2" дают разные результаты?
Что же касается чёрной консоли: на первых нескольких уроках то же будет и с Javascript. A через несколько уроков можно сделать летающую псевдографику, ползущую змейку и т.д. Сколько было интересных игрушек!
Ну, как-то же детям "объясняют" почему, скажем, в Питоне (понятно, что не только в Питоне)
0.3 + 0.6 == 0.9
возвращает False.
Как Вы объясните детям,
я ничего не буду объяснять, я скажу, что так нельзя. Потом по мере процесса разберутся. Ну примерно как в школе сначала пять на три не делится, а потом оказывается, что делится, а к концу института и на ноль делить можно.
на первых нескольких уроках то же будет
Я уже пример привёл, что не будет. Вы правда утверждаете, что псевдографика в консоли на компьютере интереснее, чем спрайтовая графика у себя на телефоне?
я ничего не буду объяснять, я скажу, что так нельзя.
Хороший препод, и лекция интересная. Школоло в голову впихнули коммуникативный закон. И тут вдруг от порядка сложения зависит результат, и без обьяснений.
я ничего не буду объяснять, я скажу, что так нельзя. Потом по мере процесса разберутся.
Да, только они попробуют, и спросят, почему же так получается.
Я вообще искренне считаю, что JavaScript - крайне неудачный язык из-за вот этих вот своих способностей успешно переваривать любые логические ошибки программиста. Это было оправдано, когда он был просто скриптовым языком для добавления элементов интерактивности к веб-страничкам, где любая ошибка была некритичной, и главное - чтобы страничка отображалась. Но когда он перерос в полноценный инструмент разработки, это всё обернулось во вред.
А для обучения программированию всё-таки лучше брать языки со строгой типизацией, потому что перейти от языков с типизацией к языкам без типизации легко, а вот наоборот - больно.
А какая проблема объяснить? "Дети, числа с плавающей точкой представляются внутри компьютера не так, как у нас на бумаге, там двоичные числа и ограниченный размер, так что будьте готовы к сюрпризам." Тем более, что та же проблема воспроизводится на обычных калькуляторах.
Школьные уроки по программированию предназначены для всех. В том числе для будущих кухарок. Их задача - показать детям, что такое программирование, чтобы помочь им с профориентацией и при этом их не мучить. А кто заинтересуется - тот пойдёт на кружок, который не для всех. И там он будет заниматься тем, что даёт больше интересных возможностей, но и требует больше усилий.
Я (и не только я) считаю, что детям смартфон до 18 лет давать в руки нельзя по целому ряду причин. И не даю. В школе, где мои дети учатся, все по старинке и карандашом по бумаге. Представьте себе, это не помешало двум моим старшим дочкам стать программистами: одна специализируется по Angular, вторая по React.
А какая проблема объяснить? "Дети, числа с плавающей точкой представляются внутри компьютера не так, как у нас на бумаге, там двоичные числа и ограниченный размер, так что будьте готовы к сюрпризам."
Там вопрос не про плавающую точку, а про трактование типов у JavaScript:
Я (и не только я) считаю, что детям смартфон до 18 лет давать в руки нельзя по целому ряду причин.
Ага, и первая из этих причин - сделать своего ребенка-подростка посмешищем среди своих сверстников, практически лишив его возможности нормально общаться с друзьями.
В школе, где мои дети учатся, все по старинке и карандашом по бумаге.
В школе и у нас телефоны вообще запрещены на занятиях. Но при этом не давать за пределами школы телефон, скажем, 11-летнему ребёнку, это уже издевательство над ним.
Tрактование типов у JavaScript - это причина, по которой я против того, чтобы учить в школе JavaScript. Даже на кружке. Лучше Python.
"Я вообще искренне считаю, что JavaScript - крайне неудачный язык" - согласен. Если его учить, то последним, а не первым и не вторым.
"лучше брать языки со строгой типизацией" - согласен: помнится, GWBASIC в она строгая.
"первая из этих причин - сделать своего ребенка-подростка посмешищем" - там, где я живу, это довольно нормально (это не в России). Если бы я видел, что это делает ребенка-подростка посмешищем среди своих сверстников, я бы на это, конечно, не пошел.
там, где я живу, это довольно нормально (это не в России).
Я в Испании живу, тут возраст "отелефонивания" примерно лет десять. Современному поколению подростков без телефонов уже нереально, они там общаются, делятся новостями и собственным контентом, и в общем-то социализируются через него. И насколько я знаю, по Европе так плюс-минус везде.
Если бы я видел, что это делает ребенка-подростка посмешищем среди своих сверстников, я бы на это, конечно, не пошел.
Проблема в том, что мы это далеко не всегда видим. Меня, например, в детстве бабушка очень старалась опекать, и с меня по этому поводу не ржал только ленивый. Но бабушка - это был последний человек, которому я на что-то бы мог пожаловаться. Поэтому она это так и не узнала, померла, так и не поняв, чего это любимый внучок её сторонился.
помнится, GWBASIC в она строгая.
GWBASIC для обучения был бы неплох, если он не был бы столь древний. Мы-то на него подсели в 1980-е как раз по той причине, что это было круто, это было ново, это был хайтек. Сейчас это безнадёжная древность сорокалетней давности. Вас бы сильно увлекли технологии, если вам бы дедушка показал, как он к лампе в патроне провод с вилкой прикручивает, и втыкает её в розетку? А для него это тоже как раз был хайтек в юности, сорок лет назад, если отмотать от 1980-х.
Ну, к рисунку можно и психологические какие-то уроки про жизнь подтянуть и про приведение типов прямо серьёзно в голову вбить
Кстати, с Юникодом там как? Написать "Привет" получится, или бНОПНЯ?
GWBASIC
Это тот самый, классический? Если так, то лучше уж QuickBASIC. Простота, необходимость, в случае чего, сделать что-то посложнее, исполняемый файл на выходе.
Мой выбор в данном случае именно GWBASIC, потому что он лучше даёт представление, как "всё это" работает "внутри": "там, внутри" нет таких понятий, как функции и подпрограммы, зато есть адрес каждой команды, переход по адресу и стек вызовов.
Но это - на обычных школьных уроках, которые предназначены для всех. Их задача - показать детям, что такое программирование, чтобы помочь им с профориентацией и при этом их лишний раз не мучить. (Scratch, например, замечательная штука, но даёт совершенно превратное впечатление о том, что такое работа программиста.) А те, кто заинтересовался, пойдут на кружок, и там уж должен быть не QuickBASIC, а что-то посерьёзнее и поактуальнее. Скажем, Python или Javascript.
Таким образом, к началу 90-х сформировались две линии эволюции языков:
Первая — языки, нацеленные на высокую производительность и возможность строить сложные системы...
Вторая линия — языки, ориентированные на удобство разработки и простоту чтения кода...
Три. Ещё - Паскаль/Delphi, которые сочетали плюсы и первых, и вторых.
Подходящий пример -- эволюция языка Fortran. Fortran 90, по сути, новый язык (с динамическим выделением памяти, указателями, ООП (в следующих редакциях), чистыми функциями и т.п., векторизацией), в который искусственно введена возможность корректной компиляции кода, написанного на старых диалектах.
Помню, Turbo Basic был ещё, от Борланда. Там использование нумерации строк было необязательным (использовалось по месту для указания, куда переходить по goto), а также компилировались exe-шники.
да братуха васик это ваще тема! не знаю че там короче эти умники на своих си крестах мутят делать им нефиг чета короче объекты там указатели именовывай-рызименовывай я ваще не вкуриваю че за прикол! если бы на васике было пилить фронт вместо джаваскрипт я бы уже проггером работал внатуре)))
Вообще-то на тех же 8ми битках в пзу были бейсики с процедурами (sub, Go sub). И с доступом к памяти через peek, poke. Вот указателей не было, это да
У меня гораздо более простое видение этой ситуации.
Была там какая-то история про Бейсик для Альтаир 8800. И как бы с этой истории началась успеховная история о какой-то там компании, в определенных кругах даже известной.
И я совершенно не исключаю, что Бейсик стал своего рода тотемом для этой компании. И именно поэтому хоть как-то "развивался" (VB, VBA, FoxPro...), а не канул в небытие. А вот, чтобы он развивался еще больше, как об этом намекает автор, нужны какие-то совсем чудовищные условия. Что-то вроде торговой федерации с Вейдером и штурмовиками )
Впрочем, к чему это могло бы привести, можно посмотреть на примере ... 1С. Почти тот же Бейсик, но без конкуренции в рамках платформы.
И я совершенно не исключаю, что Бейсик стал своего рода тотемом для этой компании. И именно поэтому хоть как-то "развивался"
Бейсик развивался не "как-то", а очень даже офигенно, Visual Basic был действительно прорывным решением для своего времени, который вообще вывел массовую разработку на качественно новый уровень.
Думаю, заслуга здесь была не у Бейсика как языка, а у решения в целом. Сыграла сама идея фреймворка со стандартными компонентами и пользовательскими обработчиками. Это она позволила относительно быстро создавать макет приложения без погружения в MessageLoop и обработку WM-сообщений. И я, опять же, не исключаю, что язык для этого решения был выбран из "тотемистических" соображений )
Впоследствии эта идея гораздо качественнее была реализована в VCL (Delphi). Затем повторена в WindowsForms и снова использована уже в VB.Net, который в принципе был не нужен, и возможно, опять из "тотемистических" соображений. Ведь J# они забросили, а VB - нет )
Думаю, заслуга здесь была не у Бейсика как языка, а у решения в целом
Конечно. Любой язык получил бы звёздный час с такой средой разработки. Собственно, Delphi это показала.
Затем повторена в WindowsForms и снова использована уже в VB.Net, который в принципе был не нужен, и возможно, опять из "тотемистических" соображений.
Скорее, для совместимости с уже сущестующим кодом. На классическом VB было слишком много всего написано, чтобы вот так просто это похоронить без возможности переноса на актуальную платформу.
Любой язык получил бы звёздный час с такой средой разработки. Собственно, Delphi это показала.
А вот C++ Builder (VCL плюс Borland C++) что-то не взлетел. У плюсовиков тогда уже сформировались свои традиции написания Windows-приложений. Не купились )
Скорее, для совместимости с уже сущестующим кодом. На классическом VB было слишком много всего написано
А это, кстати, очень непросто перенести старый VB (vbrun, p-code) на CLR. Рабочее окружение совершенно другое, и язык сильно оброс неведомыми ранее штуками. Без потерь можно перенести, разве что, какие-нибудь модули с вычислениями. С остальным будет без разницы: что в C#, что в VB.Net. "Общий" язык здесь не дает преимуществ. Возможно, это делалось для того, чтобы сохранить разработчиков на VB, но мне почему-то ни разу не приходилось видеть в "новом времени" (после 2005-2010 годов) живых VB-разработчиков. "Старые" попереезжали кто на Delphi, кто на Java/dotNet, кто на PHP и т.д. А все дотнетчики, с которыми мне приходилось пересекаться, использовали исключительно C#. Только живых VBA-разработчиков приходилось встречать. С остальным - глухо.
А у меня совсем уж более простое видение такой ситуации. VB и VBA создавались Microsoft как относительно простые инструменты для разработки приложений под Windows и MS Office. Исключительно только для этой цели и не более. По сути VB (последняя версия VB6) и VBA это есть один язык программирования, который впитал в себя все лучшее из истории BASIC'а (во всяком случае его реализаций самой Microsoft) и наполнился концептуальностью (прежде всего за счёт ActiveX и СОМ технологий) для разработки приложений в Windows и в среде объектных COM-моделей приложений входящих в MS Office для их прикладного функционального расширения. Саму задумку и реализацию всего этого проекта под названием "VB и VBA" с полным правом можно считать гениальным решением Microsoft. Дальнейшее их расширение и развитие не имеет смысла, так как "тут уже все сказано", а компании надо было идти ("ехать") дальше ("продолжать крутить велосипед"), чтобы "кормить" своих разработчиков и получать прибыль на новых технологиях и продуктах. Разработчики под Windows могут и сейчас с успехом использовать эти инструменты хотя поддержка среды разработки VB6 к большому сожалению давно прекращена, но библиотека исполнения его откомпилированного кода продолжает поддерживаться и последними версиями Windows.
"хоть как-то развивался" не потому, что был тотемом, а потому что "народ требовал". Недавно в каком-то из старых журналов попалось упоминание о том, что MS хотел прикрыть проект VB, но желание масс перевесило. Это было еще в прошлом тысячелетии.
По студенчеству был у меня приятель - учился на АСОУ. Я в то время прыгал с Паскаля на С и обратно пытался турбовизить, дергать прерывания и писать графику 320x240x256. Андрей же писал только нa qbasic, а ввиду того, что он, по всей видимости, был программистом от бога, то на все его программы я смотрел в лёгком ах..уе не понимая как можно делать такие вещи на такой кривуле, а у меня как не напишу всё время получается какой-то отстой. Всё таки умение пользоваться инструментом при большом таланте может сгладить недостатки самого инструмента.
В 90-х qbasic был ничем не хуже турбо-си или турбо-паскаля. Когда меня сишники совсем достали, я на спор написал на qbasic операционную систему реального времени для автономной работы на полигоне - она собирала данные с физических датчиков разной природы, делала предварительную обработку, и позволяла оператору параллельно обрабатывать данные в графической оболочке. Разумеется, критические по таймингу участки кода писались на ассемблере, превращались в obj-файлы и подгружались при компиляции в основную программу. Но ровно то же самое делалось бы и на Си, просто в турбо-си и турбо-паскале была замечательная возможность писать asm-блоки прямо в теле программы - вот и вся разница. Так что всё относительно.
https://www.basic.visual2000.ru/
Автора тоже зовут Андрей, в 90-х он часто публиковался в журналах со статьями про бейсик.
На скриншоте "UniBASIC" меня заинтересовало сразу несколько вещей. Во-первых, болгарское имя автора Todor Todorov, намекавшее на то, что это с большой вероятностью не американская разработка. Во-вторых, шрифт, очень похожий на применявшийся в Apple II. В-третьих, системное приглашение монитора ромбиком, не похожее на эппловскую звездочку.
Все это прозвучало для меня как приглашение разобраться, что это за зверь такой, и на чем оно работает.
Начинаю раскручивать. Big-endian порядок байтов в инструкции JMP сразу отбрасывает 6502 и 8080 (да и я помню без справочника, что RTS в 6502 — это $60, а в 8080 такой мнемоники нет, есть RET). Перед нами, скорее всего, 6800, что подтверждается списком регистров A, B, X, SP.
Сверяю опкоды по справочнику https://www.8bit-era.cz/6800.html - действительно, $39 - RTS, а $7E - это JMP. Но $3F - это однобайтная команда SWI (Software Interrupt). На скриношоте же видно, что она занимает два байта (3F 30).
Кроличья нора оказалась глубже, чем казалось. Сначала я пытался найти отличия в наборе инструкций для родственников 6801, 6805 и 6809, но все они показали тот же самый однобайтный SWI.
Пришлось подойти с другой стороны. "UniBASIC by Todor Todorov" указал на болгарский компьютер Пълдин 601, построенный на CM601 - болгарском клоне 6800. Может в клон внесли изменения?
Нахожу эмулятор Пылдина, скачиваю, изучаю. Там такой же однобайтный SWI, как и в оригинальном процессоре.
И тут приходит идея. SWI - это же софтовое прерывание. А что, если обработчик прерывания умеет брать следующий байт, интерпретировать его и возвращать управление на последующий за ним байт? Тогда это уровень абстракции чуть выше, чем просто эмуляция процессора.
Нахожу в репозитории каталог native-src - исходники программ на самом Пылдине. А там действительно употребляется в хвост и гриву мнемоника int с последующим байтом.
И есть файл PYLDIN.TXT. Явно README какой-то. Подбираем кодировку, оказалась MIK. Конвертирую в UTF-8 и получаю ясный текст на болгарском языке. Сразу ищу слово SWI. Бинго! Фрагмент документации расставляет все точки над «i». (Перевод оставляю в качестве самостоятельного упражнения для читателя).
ПРЕДУПРЕЖДЕНИЕ: С оглед на осигуряване на съвместимост със следващи версии на операционната система, се счита за уместно всички програми, използващи функции на операционната система да осъществяват това по единен протокол, чрез използване на инструкцията SWI. Всяко друго директно обръщение към кода на операционната система се счита за нелегално и не се поема никаква отговорност за неприложимостта на такива програми в бъдеще.
Формата на обръщението към операционната система е инструкцията SWI, следвана от един байт, съдържащ номер на функцията (interrupt). Номерата са разпределени по следния начин: $ 00 - 7F - запазени за UNIDOS
$ 80 - FF - свободни (за използване от езици и потребителя)
А в файле BIOS.ASM находим и исходник того самого дизассемблера, что на скриншоте:
org $F000
int $30 ;call monitor
rts
jmp putc
так и обработчик прерывания SWI, который достает адрес возврата из стека, извлекает параметр, увеличивает адрес и запихивает новый адрес обратно в стекswihndl proc ; драйвер за обработка на SWI
sei ; осигурява псевдо-инструкцията INT
inc indos ; ниво на вложеност
tsx
lds 5,x ; компенсиране на PC за номера на
des ; интеръпта
pula ; номер на интеръпта
ins
sts 5,x
txs
psha
Кто бы мог подумать, что за обычным скрином оказалось столько информации и забавная страница из истории болгарского компьютеростроения. Спасибо, было прикольно.
PS. Фотографии Пылдина:
http://www.leningrad.su/museum/show_calc.php?n=432
https://olimex.wordpress.com/2015/01/12/retro-computer-puldin-the-only-bulgarian-8-bit-computer-developed-from-scratch/
Ничего себе, суб-расследование Вы провели. Ностальгия и глубокое погружение в дисциплину на лицо. 👍
Пълдин (древнее название города Пловдив) был задуман как концентратор данных или учебный/домашный компютер с ценой ниже компютеров из серии Правец-8Х, но так как он являлся оригинальной болгарской разработкой, был в целом несовместим с наличным ПО, а собственное такое отсуствовало. Хотя его формат файловой системы был MS DOS совместимым.
Поетому (как и из за не очень удобной мембранной клавиатуре) широкое распространение не получил. По одним источником произвели около 30000 штук, по другим - около 3000.
А что, если обработчик прерывания умеет брать следующий байт, интерпретировать его и возвращать управление на последующий за ним байт?
Емнип в Радио86рк таким же способом делался аналог print. Null terminated строка сразу после call print. Пару байт экономится на передаче параметра, красивое. Древняя магия, сейчас так не делают. Понапридумали своих ABI..
Перевод оставляю в качестве самостоятельного упражнения для читателя
Читается легко и так.
>>QuickBASIC/Basic Compiler от Microsoft, который переводил код BASIC в исполняемый .EXE
Ничего он не переводил, а просто упаковывал исходник в виде ресурса и прицеплял его к exe интерпретатора
Это такая бестактная наглая ложь,что она выдернула меня из постели и заставила написать комментарий.
Не поленитесь скачать QuickBasic, написать какую-нибудь простенькую программу, скомпилировать, а потом посмотреть полученный EXE-файл в hex-редакторе и найдите там исходник.
ЕМНИП в Quick/PDS/QBasic/VBDos/VBWin (до пятой версии вроде) исходный код на Basic преобразовывался в P-Code виртуальной машины который потом, во время исполнения EXE-ка, обрабатывался встроенной виртуальной машиной.
в Quick/PDS/QBasic/VBDos/VBWin
Всё смешали в одну кучу.
Не надо «ЕМНИП», я в качестве реакции на «бесподобные» комментарии под данной статьёй написал свою статью: https://habr.com/ru/articles/973594
Всё смешали в одну кучу.
Так там ВЕЗДЕ крутилась виртуальная машина исполнявшая Pcode, и в IDE и в EXE. Так что объединение вполне корректное. :)
Не надо «ЕМНИП», я в качестве реакции на «бесподобные» комментарии под данной статьёй написал свою статью: https://habr.com/ru/articles/973594
Поржал над вашим опусом, было очень весело. 8D
Я то грешным делом думал что вы разберете утекшие сырки Qbasic, или (чем черт ни шутит) сырки Quick/PDS/VBDOS если они где то они всплыли. Но нет. Не в эту смену. 8Р
Так что объединение вполне корректное. :)
Нет, не корректное.
У QuickBasic в скомпилированном виде не было никакого Pcode и никакой виртуальной маины. Статья это чётко демонстрирует. У Visual Basic виртуальная машина в скомпилированном виде была, но во-первых, не в EXE, а в msvbvm?0.dll, а во-вторых, она не крутилась, а лежала там мёртвым грузом, если проект был скомпилирован в Native Code.
Basic - это предельно упрощённый Fortran, адаптированный для людей, не являющихся ни профессиональными программистами, ни профессиональными математиками. Собственно, он и был создан для написания кода студентами, не изучающими программирование.
В качестве языка для обучения программированию лучше всего охарактеризовал Basic Дейкстра: "Студентов, ранее изучавших Бейсик, практически невозможно обучить хорошему программированию. Как потенциальные программисты они подверглись необратимой умственной деградации".
Во времена первых 8-битных персональных компьютеров широкому распространению Basic способствовало то, что интерпретатор языка мог работать на компьютерах с предельно малым объёмом ОЗУ. Но сама концепция статически типизированного интерпретируемого языка программирования - эволюционный тупик. И язык начал умирать в 1991 году - с появлением более удобного и рассчитанного на ту же самую аудиторию динамически типизированного Python. Лишь позиция Билла Гейтса, пихающего Basic во все щели, позволила удержать этот язык на плаву ещё несколько десятилетий.
P.S. ИМХО, лучшие диалекты Basic - QuickBasic / QBasic (интерпретатор и компилятор с очень похожими структурными диалектами языка, немного отличающимися семантикой подпрограмм): они прекрасно подходили для прототипирования в задачах, не связанных с обработкой текстов. Но вот VB - это уже деградация.
Дейкстра обеспокоился, что практически любой может в программера, вместо шести лет платного обучения. Такое случается сплошь и рядом. И до сих пор. В том числе и в школьной программе. Ничего удивительного.
Тупик - это то что сейчас - усложнение языка до уровня PhD - > и так далее, результат - повышенные риски для цивилизации в случае форс-мажора.
Вы применяете ИТ-мерки конца четверти XXI-ого века к 70-ым годам XX-ого века (т. е. 50-ти летнему прошлому выч.техники), когда микро - ЭВМ были всего с 4Кб (в лучшем случае 8Кб) оперативной памяти без внешней и ввод программы и данных на перфоленте. Поэтому, что возможно было делать на этих ресурсах, то делали. В данном случае и интерпретатор для простенького BASIC'a. Никогда и "никаким боком" реализации BASIC'а не соотносились тогда (а сейчас и тем более) с Fortran'ом - мощным компилируемым языком программирования ориентированным на компьютеризацию в первую очередь математических и инженерно-технических задач и успешно выполняющим свою миссию и в XXI-о веке. Что ж, приходится делать ликбез, хотя по Вашему возрасту это должны помнить.
Продолжение ликбеза.
VB и VBA создавались Microsoft как относительно простые инструменты для разработки приложений под Windows и MS Office. Исключительно только для этих целей и не более. По сути VB (последняя версия VB6) и VBA это один мощный язык программирования, который впитал в себя все лучшее как из истории BASIC'а (во всяком случае его реализаций самой Microsoft), так и других языков с читабельным синтаксисом, наполнился концептуальностью (прежде всего за счёт ActiveX и СОМ технологий) для разработки приложений в Windows и в среде объектных COM-моделей приложений входящих в MS Office для их прикладного функционального расширения. Саму задумку и реализацию всего этого проекта под названием "VB и VBA" с полным правом можно считать гениальным решением Microsoft (а может и самого Б. Гейтса). Дальнейшее расширение и развитие проекта не имело смысла, так как "все было сказано и сделано", а компании надо идти ("ехать") дальше ("продолжать крутить велосипед"), чтобы "кормить" своих разработчиков и получать прибыль на новых технологиях и продуктах. Разработчики под Windows могут и сейчас с успехом использовать эти инструменты хотя поддержка среды разработки VB6 к большому сожалению давно прекращена, но библиотека исполнения его откомпилированного кода продолжает поддерживаться и последними версиями Windows.
BBC Basic созданный для машины BBC Micro был с самого начала весьма гибким языком структурного программирования. Более того, он развивается по сей день, в него добавили поддержку SDL2 и портировали на многие платформы. Есть ряд примеров достаточно сложных игр с 3D графикой. На мой взгля это самый подходящий вариант ЯП для школьника младших классов. После него не страшно переходить к изучению Си.
REM Geography quiz
PRINT "What is the capital of France:"
PRINT "a) Paris"
PRINT "b) London"
PRINT "c) Madrid"
INPUT "Enter a,b or c: " Reply$
CASE Reply$ OF
WHEN "A", "a": PRINT "Correct"
WHEN "B", "b": PRINT "Sorry, that's England"
WHEN "C", "c": PRINT "Sorry, that's Spain"
OTHERWISE: PRINT "Sorry, invalid response"
ENDCASE
ENDНомера строк давно являются необязательными. Вот пример более длинной программы на BBC Basic с процедурами и структурами.
После него не страшно переходить к изучению Си.
Если язык хороший и годный - зачем куда то переходить? Если конечная цель С - почему сразу не учить С? На нем можно писать в basic-style.
Действительно лучше сразу изучать Си. Но детям требуется какой-то эффект быстро и сейчас (проиграть мелодию, нарисовать картинку линиями). В этом смысле Basic более пригоден. Чтобы добраться до графического контекста на Си, придется написать километры кода попутно освоив ряд нетривиальных концепций и парадигм.
Каким бы хорошим не был Basic, это всё равно интерпретируемый язык. Взрослые парни пишут на компилируемых языках. В этом смысле все питонисты - дети. ;)
Каким бы хорошим не был Basic, это всё равно интерпретируемый язык. Взрослые парни пишут на компилируемых языках.
Бейсик стал компилируемым ещё в 1980-х, с появлением Турбо Бейсика :)
AFAIK, он не был компилируемым как таковым, просто среда упаковывала интерпретатор с кодом в один .EXE файл. Нормальных компиляторов с "Васика" я не встречал.
По-моему, TB был как раз честным компилятором. Исполняющую среду с кодом в один EXE паковал Visual Basic
Существует современный язык программирования, нечувствительный к регистру, без точек с запятой, слегка многословный, с END IF и т. д. Называется он Фортран.
Порог входа действительно был низкий. Не имея никакого профильного образования, работая в офисе в 90- тые простым "специалистом" - письма, инвойсы, договоры, телекс - наткнулся на qbasic. Начал щелкать да хэлп открывать и буквально на второй-третий день написал работающий код симулятора "однорукого вора". Еще там что-то по мелочи. Зашел в кабинет реальный специалист по ИТ, сказал что-то обесценивающее про яп. Типа зачем? Оно тебе надо? Ещё как надо, оказывается.
именно BASIC стал входным билетом в IT для целого поколения...
не совсем так, BASIC был не более чем простым и удобным языком для людей профессий прямо не связанных с программированием, типа для решения маленьких, но нужных задач по своей специальности (Bill Gates конечно исключение :) ),
именно так было задумано Kemeny и другими участниками проекта в Dartmouth College, вообще BASIC = Beginners All-purpose Symbolic Instruction Language,
задача была сделать что-то простое и доступное насколько возможно для использования студентами всех специальностей, сравнивать его с языками системного программирования вероятно не очень правильно,
вообще для лучшего понимания - Dartmouth College это один из Ivy League, John Kemeny (позже ставший президентом Dartmouth), это человек уровня Ричарда Фейнмана, с которым вместе участвовал в Manhattan project, в 1963 году им подарили вполне приличную машину GE225 (см. ниже), для которой они сами написали систему разделения времени, чтобы сделать BASIC доступным студентам всех специальностей
для людей с фантазией другой вопрос - что и как было бы с языками программирования без работ Zuse (Plankalkul), учитывая что в рабочей группе по Algol (58/60) были в том числе участники семинара Zuse по компиляции Plankalkul, на этом семинаре впервые обсуждались идеи использования стека для компиляции выражений, организации блоков с локальными переменными и пр. , (imho) Algol 60 был вряд ли возможен без работ Zuse по Plankalkul с вытекающими последствиями, которые типа трудно представить
вообще BASIC = Beginners All-purpose Symbolic Instruction Language
Тогда бы он назывался BASIL
Beginner’s All-purpose Symbolic Instruction Code
Вот совершенно не скучаю по Бейсику. Писал раньше и на VB, и на VBA (Excel/Word), и на VBScript. А несколько лет назад изучил Python, и теперь счастлив до невозможности, ведь он мощнее на порядки. И лаконичный, и удобный. На нём сейчас можно написать вообще всё что угодно, через вызовы сторонних библиотек, коих тысячи :) Хоть низкоуровневое общение с контроллерами через COM порт. Хоть обработку файлов. Хоть веб. Хоть обработку изображений через OpenCV. Он конечно медленнее по сравнению с С/Java, ну и ладно. Если что-то критичное, можно и на С/Java сделать, а для всего остального некритичного зато код писать быстрее
На нём сейчас можно написать вообще всё что угодно, через вызовы сторонних библиотек, коих тысячи
Вот именно поэтому он и мощнее (я против Python ничего не имею, ровно наоборот). Автор-то фантазирует насчёт развития Basic, как одного из основных ЯП. Можно предположить, что в таком случае и под него писались бы мегатонны библиотек, что значительно бы расширило возможности, например до уровня того же современного Python (почему нет?).
Под Питон писали библиотеки в огромных количествах еще тогда, когда его не замечали корпораты. И стандартная библиотека была богатая(как принцип) и постоянно улучшалась. Почему-то. А в Бейсиках(любых) - почему-то наоборот! Даже доступ к .Net. не помогает.
Соглашусь, но тому есть объективные причины:
1. Python изначально задумывался и разрабатывался сильно позже BASIC. Гвидо уже "стоял на плечах предшественников" и мог объективно оценивать достоинства и недостатки ЯП, уже созданных к этому времени;
2. Python изначально был открытым, BASIC - проприетарным. Писать массово библиотеки под это - такое себе...
Что именно мешало написать мегатонны разноплановых библиотек для VB, таких же по широте возможностей, как наплодили для Python, в виде COM-библиотек? Написать из можно было хоть на самом VB (как пишут библиотеки для Python-а на самом Python-е), так и на практических любых других языках (например C++). И что самое главное, использовать их в таком случае можно было бы не только из VB, но из кучи других близкородственных сред (VBA, VBScript, JScript), нейтральных (C, C++) и не очень близкородственных (PHP) сред. Благодаря тому, что технологии COM/ActiveX предлагали многим какой-то один чётко зафиксированный языко-независимый формат/механизм/протокол взаимодействия.
Что именно мешало написать мегатонны разноплановых библиотек для VB, таких же по широте возможностей, как наплодили для Python, в виде COM-библиотек?
Вы сами ответили на этот вопрос: VB поддерживал СОМ-библиотеки. Что такое СОМ-библиотека в 1990-е? Нечто с очень ресурсозатратным связыванием и с геморройной установкой - банально просто скопировать нельзя, нужен инсталлятор для регистрации этого добра в реестре и прибивании гвоздями к локации.
Нечто с очень ресурсозатратным связыванием
Господи... ужас... шок... фейспалм.
Неужели вслед за статьёй что QB и VB не был интерпретируемым языком, а генерировали настоящий полноценный машинный код, нужно писать следующую, с разоблачением новой байки?
С другой стороны, у вашего ответа есть ещё и второй дно: даже если бы всё что вы пишите, было правдой (а оно не было), то удивительно, что в сравнении с Python у последнего всё так же, если не хуже.
Но вернёмся к очень ресурсозатратному связыванию. Я не уверен, что именно вы понимаете под связыванием, но, в любом случае, «очень ресурсозатратное связывание» существует только в вашем воображении.
Если вы про то связывание, которое имеет место в момент вызова метода у объекта, то вопреки тому, что вы там себе придумали, вызов любого метода COM-объекта НИЧЕМ НЕ ОТЛИЧАЕТСЯ от вызова метода C++-класса, объявленного с ключевым словом virtual, за исключением использования соглашения stdcall вместо thiscall (указатель на this передаётся не в регистре ECX, а первым параметром на стеке).
То есть буквальноSomething.Foo()в VB ничем не отличается отSomething->Fooв С++, при условии, что Foo объявлена какvirtual __stdcall returntypename Foo() = 0;
На выходе будет сгенерирован код типаmov eax, dword [Something]
mov ecx, dword [eax] ; Получаем адрес vtbl
push eax ; Пушим this неявным первым аргументом
call [ecx+nnnnn] ; Вызываем метод foo, где nnnn — смещение в vtbl
Ну и каким боком это связывание очень ресурсозатратное или какое-то сложное?
Это называется поздним связыванием в мире C++ (в противовес раннему связыванию, происходящему при линковке, если метод класса был не виртуальным), но в мире COM это наоборот называется ранним связыванием. А есть ещё и позднее связывание в мире COM, и вы наверное имели в виду его сложность и ресурсоёмкость. Только вот использование позднего связывания — это фича, опция, а не обязанность. Не хотите: можете не использовать его со стороны вызывающего кода (на VB). Не хотите — можете не имплементировать его на стороне реализации COM-объекта. Не обязательно вообще реализовывать механизм позднего связывания. Это в технологии ActiveX/OLE Automation ваш coclass должен быть dual-ным и поддерживать IDispatch и disp-интерфейсы для обычных COM-интерфейсов. Но никто не заставляет вас делать поддержку всего этого, если вам не нужно или обременительно.
Ярчайший пример: библиотеки DirectX, Direct3D того времени (6, 7, 8, 9). Условно возьмём библиотеки d3d9.dll — всё взаимодействие с Direct3D осуществляется через COM-интерфейсы, через работу с этими объектами и вызовы их методов. Это библиотека написана вообще без прицела на то, чтобы её использовали из VB. Создатели Half-Life 2, например, писали не на VB и использовали Direct3D, равно как и создатели сотен других игр.
Тем не менее, использовать её VB легко и просто, равно как и любую другую подобную библиотека, будь она написана в том же духе.Если же под связыванием подразумевается то, что Microsoft называет термином «активация» — то есть установление связи между COM-клиентом (вызывающей стороной) и COM-серверов, то и здесь всё не так, как вам хочется думать.
В рамках COM не установлено и не регламентируется, как вы найдёте DLL-библиотеку, реализующую COM-объект, как с ней провзаимодействуете и как получите указатель на COM-объект. Как хотите, так и делайте.
Это в рамках технологии ActiveX, чтобы не было бардака и разнобоя, установили единый концепт и единый способ (чтобы серверы регистрировали в реестре свои классы по их уникальным идентификаторам CLSID, а также регистрировали маппинг между человеко-читаемыми идентификаторами ProgId и 128-битными числовыми CLSID-ами, а также редактировали бы для серверов местоположение TLB и т.д. Просто чтобы каждый программист не изобретал велосипед и чтобы все программы использовали единый отлаженный механизм (подразумевающий поиск в реестре, который вы конечно же делаете не сами).
Но это, опять же, как и в случае с поздним связыванием через IDispatch, по вашему желанию. Не хотите — не надо. Вот библиотека d3d9.dll не зарегистрирована в реестре. Ей не нужно регистрироваться в реестре. Она просто лежит в system32 и экспортирует обычную функцию Direct3DCreate9(). Вы импортируете эту функцию, вызываете, и вуаля — увас указатель на COM-объект. Точнее указатель на COM-интерфейс IDirect3D9 некоего объекта, олицетворяющего всю библиотеку Direct3D. Работаете сним, вызывайте его методы, и на этом будет построено всё ваше взаимодействие с Direct3D.
Для свой собственной библиотеки вы можете делать то же самое. Экспортируйте функцию, которая вернёт корневой объект вашей библиотеки, а вызыващая сторона пусть дёрнет эту функцию и дальше работает с корневым объектом. Вы можете назвать функцию как угодно. Вы можете назвать библиотеку как угодно. Вы можете положить её куда угодно (вовсе не обязательно класть её в system32). Лишь бы вызывающая сторона могла дёрнуть из неё экспортируемую функцию.
Но вы можете пойти дальше и вместо этой дикости воспользоваться стандартным унифицированным хорошо отлаженным механизмом. Зарегистрировать библиотеку в реестре. Точнее в реестре регистируется не только сама библиотека, сколько классы, в ней реализованные. Тогда вам не нужно отдельно документировать, как достучаться до вашей библиотеки и какие функции импортировать и вызывать, чтобы породить экземпляр какого-нибудь класса или получить корневой объект какой-то иерархии объектов. Все приложения будут использовать одинаковый механизм для создания ваших классов, в том числе их можно будет создавать и из скриптовых языков, а если объекты поддерживают ещё и IDispatch — можно будет не только создавать, но и вызывать у них методы.
Но и тут можно пойти дальше. Я не понимаю, с чего ради способ этой активации считается каким-то ресурсоёмким.
Система дарует вам функцию CoCreateInstance, как бы говоря, что теперь вы можете породить экземпляр любого класса, зная только уникальный идентификатор класса. Вам не нужно заботиться о том, где найти DLL-файл, загружать его, заботиться о том, какую функцию там импортировать и как её вызывать. Все стандартизированно, всё одинаково у всех библиотек и вам не нужно ничего делать самому.
Для этого системная реализация CoCreateInstance делает пару простых вещей:
1. Вызывает CoGetClassObject, чтобы получить ссылку на объект, олицетворяющий сам класс (экземпляр которого вы намереваетесь создать)
2. Запрашивает у этого объекта интерфейс IClassFactory и у него вызывает метод CreateInstance.
Только и всего. Сама же CoGetClassObject должна как-то находить DLL-библиотеку, внутри которой реализован не только сам класс, но и отдельный вспомогательный объект, олицетворяющий этот класс. Для этого CoGetClassObject делает несколкьо простых вещей:
1. Ищет в реестре по предоставленному уникальному идентификатору класса ключик, содержащий полный путь к DLL-файлу.
2. Вызывает LoadLibrary(), чтобы загрузить этот DLL-файл.
3. У загруженной DLL вызывает экспортируемую оттуда функцию DllGetClassObject — и возвращает ссылку на объект, который отдала DLL-библиотека.
Ничего тут нет ресурсоёмкого. В отличие от работы с обычной DLL-библиотекой, пусть даже не COM-библиотекой, разница только в том, что имя/расположение DLL-файла не жёстко захардкожено, а ищется в реестре, а затем, вызывается конкретно определённая функция, чтобы через неё выйти на фабрику класса и запросить создания нового экземпляра нового класса.
В итоге создание нового экземпляра это:
1. Получение полного имени файла из реестра.
2. hmod = LoadLibrary(..._
3. funcptr_GetClassObject = GetProcAddress(hmod, "DllGetClassObject")
4. IClassFactory* cf = funcptr_GetClassObject( ... CLSID ...)
5. cf->CreateInstance(...)
И всё это обычные вызовы в духе Си/Си++.
Я уверен на миллион, что это менее ресурсоёмко, чем вещи, которые происходят под капотом Python, когда он встречает строкуfrom fooo.baar.baaz import yetanothershit
Так что слова о том, что там делается «нечто очень ресурсозатратное» вообще не в тему.
Но второй упрёк был в том, что первый пункт этого списка требует, чтобы в реестре были соответствующие ключики (чтобы по CLSID найти DLL файл). В общем-то да, требует, и это логичная мера, придуманная Microsoft, чтобы побороть DLL hell. Не понятно, почему нужно бояться регистрации DLL в файле.
НО ЕСЛИ ВАМ ПО КАКОЙ-ТО ПРИЧИНЕ НЕ НРАВИТСЯ РЕГИСТРАЦИЯ В РЕЕСТРЕ — не делайте её. Механизм порождения нового экземпляра класса полностью документирован. Все вот эти шаги из 5-пунктного списка выше полностью были документированы. Если вы хотите использовать CoCreateInstance для быстрого и лёгкого создания нового объекта, то ей нужно, чтобы в реестре был ключик. Но если вам религиозные соображения, внутренние страхи или другие объективные факторы не позволяют прибегнуть к этой регистрации в реестре, просто делайте сами вручную эти 5 действий, только в качестве первого пункта вместо поиска в реестре делайте что-то другое. Напишите свой вариант CoCreateInstance, которая вместо поиска нужной DLL в реестре ищет её где-то в ином месте. В ini-файле, в файле MyCoolAppLibrariesPaths.txt, либо пусть там будет захардкожено имя библиотеки, а библиотека лежит рядом с программой. И всё, проблема решена.
Для вашего удобства и искоренения проблемы DLL hell вам предложили способ с реестром, с централизованным местом регистрации всех ActiveX-серверов, но если вам это не нравится, порождайте объекты по своему, как вам нравится. Механизм порождения объектов не засекречен и документирован.
Но есть вариант ещё покруче. Сколько лет как вышла Windows XP? Начиная с Windows XP придуман способ показать COM, в каком же DLL-файле живёт тот или иной класс (по его CLSID) не прибегая к созданию каких бы то ни было ключей в реестре. А значит не нужен доступен в реестр, не нужна инсталляция, не нужны админские права (они в общем-то и для регистрации в реестре не особо нуждны, потому что в HKEY_CURRENT_USER есть свой под раздел profile-specific регистраций.
Суть способа — манифесты. Вы просто делаете XML-манифест и либо кладёте его отдельным файлом рядом со своим приложением, либо прямо в ресурсы EXE-файла его вшиваете. В манифесте нехитрыми XML-нодами указываете, что вам известны вот такие-то CLSID-ы и что искать их нужно в таких-то DLL-файлах.
Всё, начиная с Windows XP, вы можете использовать стандартный способ порождения экземпляров желаемого класса по его CLSID-у (либо ProgId-у), но при CoCreateInstance не пойдёт ничего искать в реестре, если она нашла это в манифесте.
Без регистрации. Без установки. Без админских прав. Уже четверть века этот способ доступен. И это не пасхалка, это документированный способ.
И для примера небольшой сниппет, касающийся упомянутого ранее Direct3D 9.
Вот такой сниппет:
Public Function TestThisStuff() As Long
Dim D3D_RootObject As IDirect3D9
Set D3D_RootObject = Direct3DCreate9(32)
TestThisStuff = D3D_RootObject.GetAdapterCount()
End FunctionЗдесь просто создаётся корневой объект объектной модели D3D и через него мы дёргаем метод GetAdapterCount(), чтобы узнать число видеоапаптеров в системе. Можно было и какую-то примитивную 3D-игру написать типа бильярда, но смотреть на это в дизассемблере было бы не весело. Поэтому просто такой наипростейший пример.
На C++ то же самое выглядело бы вот так:
long TestThisStuff()
{
IDirect3D9* D3D_RootObject;
D3D_RootObject = Direct3DCreate9(D3D_SDK_VERSION /* 32 */);
return D3D_RootObject->GetAdapterCount();
}Я знаю, что этот код содержит баг
С C++-коде выше недостаёт вызова D3D_RootObject->Release() перед возвратом и возникает нарушение подсчёта ссылок/утечка памяти. По феншую указатель на IDirect3D9* в шаблонный враппер _com_ptr_t<>
Если скомпилировать этот VB-сниппет, то получится исполняемый файл, который просто тупо импортирует 1 функцию из D3D9.DLL:
Если посмотреть дизасм функции TestThisStuff, то получим следующее:
Не сильно-то это отличается от того, чтобы сгенерировалось для аналогичного C++-кода (только там бы автоматически не было установки хендлера исключений и копирования/освобождения ссылки на объект (за которым стоит IUnknown::AddRef и IUnknown::Release для правильного подсчёта ссылок).
Ну и что здесь происходит? Сначала просто вызывается функция из DLL, точно так же, как была бы вызвана, к примеру, функция CreateProcessA из kernel32.dll — в ответ функция возвращается ссылку на корневой объект объектной модели D3D. И сразу же у этого объекта дёргается метод GetAdapterCount, через vtbl, метод является 4-м по счёту у интерфейса IDirect3D9, поэтому его смещение в vtbl — 0x10. поэтому тут мы видим CALL [ECX+10]
Где здесь пресловутое очень ресурсоёмкое связывание? Кто мешает использовать такое же в своих приложениях или для своих библиотек?
Выводы:
Не хотите для своих библиотек использовать единый для всех унифицированный способ с помощью которого система сможет находить вашу DLL и делать все манипуляции, требуемые для создания нужного вам объекта — не делайте. VB сможет работать с такой библиотекой.
Либо можете использовать этот унифицированный способ (экспортировать из библиотеки DllGetClassObject, возвращающую указатель на фабрику класса), но если вам претит регистрация в реестре, можете в конкретно своём случае эту библиотеку не регистрировать в реестре, а вместо этого в своём приложении вручную и самостоятельно находить библиотеку, самостотельно загружать её, самостоятельно вызывать DllGetClassObject и самостоятельно вызывать CreateInstance у фабрики классов. Тогда в будущем, если вы перестанете бояться, вы сможете начать регистрировать эту библиотеку, ничего в ней не переделывая, но пока что вы можете пользоваться ею, избегая регистрации.
Либо, если вы приняли для себя факт существования Windows XP или более поздних систем, вы можете ни на уровне библиотеки не делать ничего экстраординарного, ни на уровне клиентского приложения тоже не делать ничего экстраординарного, но просто вместо регистрации в реестре положить рядом с приложением саму библиотеку и манифест-файл.
А теперь что касается двойного дна у комментария, про котрое я сказал в самом начале. Изначально я в предшествующем комментарии неаписал: что мешало наплодить миллион библиотек, как это сделали в сообществе Python? На что был ответ, что всё это ресурсо-ёмкое и вообще надо регистрировать в реестре. Вроде бы как мы выяснили, что ничего там ресурсоёмкого нет, а регистрация в реестре не единственный вариант, а имеется альтернатива. Но даже если бы всё было так, хочется спросить: а разве в Python поиск библиотека не более ресурсоёмкий? А разве в Python вызов метода класса у объекта-экземпляра — не более ресурсоёмкий? А разве в Python не нужно так же инсталлировать/регистрировать библиотеку вызовом какого-нибудь pip install?
Но и тут можно пойти дальше. Я не понимаю, с чего ради способ этой активации считается каким-то ресурсоёмким.
Пфф. Судя по тому, как вы хорошо всё это помните, вы работали уже в 90-е годы. И что, вы реально забыли, как пара простых вещей, которые делает системная реализация CoCreateInstance, тормозит? Вы правда считаете, что поискать по реестру (иерархическая база данных без индексов) в 1995-м ключик и загрузить нужную библиотеку - это было быстро?
Вы же не натягивайте 2025-й на то время. Там были другие компьютеры, с другими возможностями.
На что был ответ, что всё это ресурсо-ёмкое и вообще надо регистрировать в реестре. Вроде бы как мы выяснили, что ничего там ресурсоёмкого нет, а регистрация в реестре не единственный вариант, а имеется альтернатива.
Вы манипулируете. И ресурсоёмкое, и неудобное, и "альтернатива" на у разработчиков VB не была распространённой практикой.
Но даже если бы всё было так, хочется спросить: а разве в Python поиск библиотека не более ресурсоёмкий?
Как минимум, там напрочь отсутствует взаимодействие с какими-либо сервисами ОС, кроме файловой системы. Он просто подхватывает то, что лежит у него в папке. И да, не забывайте, что Пайтон появился в 1991-м, VB тогда не умел в компиляцию, как я уже писал, и не будет уметь ещё шесть лет, а потом поживёт четыре года и станет deprecated.
(иерархическая база данных без индексов) в 1995-м ключик и загрузить нужную библиотеку - это было быстро?
Почему это без индексов? Там хеш-таблиц. Поиск в реестре весьма быстрый.
И ресурсоёмкое, и неудобное,
Что именно ресурсоёмкое?
Если ресурсоёмким был поиск в реестре (и на этом всё), то во-первых мы выяснили, что была альтернатива. То что альтернатива не была распространённой — это не аргумент, потому что это социальный фактор, а мы о технической стороне говорим. К социальным факторам его сводить не надо, потому что сам первоначальный вопрос взывает к социальному фактору: с чего ради один подход взлетел, а второй не взлетел.
Вдобавок к этому, если кому-то надо было создавать сотни тысяч объектов в секунду, то достаточно было просто 1 раз получить объект-фабрику и потом у неё вызывать метод CreateInstance, а не сотни тысяч раз искать в реестре. Более того, я почти уверен, что внутри OLEAUT32.DLL был кеш на этот случай.
Как минимум, там напрочь отсутствует взаимодействие с какими-либо сервисами ОС, кроме файловой системы.
Ха-ха, как будто файловая система это какая-то мелочь. Если бы файловая система была невесомо быстрой, никто бы не изобретал реестр, а все опции, настройки и прочее, что обычно хранится в реестре, просто распихали бы по микроскопическим файлам файловой системы, которая такая же иерархическая, как файлы. Но нет, сделали реестр.
Да файловая система куда большее зло.
VB тогда не умел в компиляцию, как я уже писал, и не будет уметь ещё шесть лет,
Он умел, просто это компиляция не в машинный код, а в бай-код. В самом слове компиляция нет никакого намёка на машинный код, поэтому самая настоящая манипуляция — уклоняться называть компиляцию в байт-код собственно компиляцией. Не нативность цепочки инструкций по отношению к CPU даёт процессу получения этой цепочки по праву называться компиляцией, а тот факт исходный код был разобран, его синтаксис проверен, его логическая структура (вложенность блоков) верифицирована, связанность идентификаторов верифицирована, замысел программиста был переведён в последовательность макро-операций, при этом выполнены все вычисления, которые можно выполнить на стадии компиляции, элиминированы пути исполнения, который никогда не достижимы, устранены избыточные макро-операции (вроде перекладываний данных туда сюда). Так что я не принимаю больше провокационных высказываний, что он не умел в компиляцию. Я люблю native code, но в контексте данного дискурса свет на нём клином не сошёлся.
Но ко всему прочему, можно подумать, что Python тогда умел в компилцию в native code?
(иерархическая база данных без индексов) в 1995-м ключик и загрузить нужную библиотеку - это было быстро?
Почему это без индексов? Там хеш-таблиц. Поиск в реестре весьма быстрый.
Оу, напомню, у нас на дворе 1995-й год. В реестре вин95 раздел HKCR ни разу не хеширован, поиск идёт прямым сканированием. И это самый большой раздел реестра, минуточку.
А, забыл добавить, ещё он разделен между двумя файлами, user.dat и system.dat. Сначала ищем в первом, потом во втором.
То что альтернатива не была распространённой — это не аргумент, потому что это социальный фактор, а мы о технической стороне говорим.
Распространять компоненты VB как устанавливаемые OCX-элементы, это не социальный фактор, а как раз дефолтный, предусмотренный дизайном IDE, способ. Потому и ставший основным.
Если бы файловая система была невесомо быстрой, никто бы не изобретал реестр
Я не уверен, что причиной изобретения реестра были какие-то там проблемы с файловой системой. Другие ОС как-то обходятся без единой иерархической базы данных настроек ОС и приложений, и не могу сказать, что от этого они стали медленнее.
Он умел, просто это компиляция не в машинный код, а в бай-код.
Ок, этот формальный факт вот вообще никак не имеет значения в обсуждаемом контексте. Главное тут то, что он не компилировал в то, что может быть выполнено непосредственно, без участия исполняющей среды.
Но ко всему прочему, можно подумать, что Python тогда умел в компилцию в native code?
Нет, конечно. Но по крайней мере, он в этом плане не имел недостатка перед VB.
Писали вроде. Я довольно далек от VB, но в период его расцвета неоднократно встречал упоминания о том, что в Буржуинии рынок VB компонентов довольно развит. Возможность использования которых преподносилось как достоинство Delphi. который тогда набирал популярность в exUSSR.
Да речь не о визуальных компонентах, а о просто библиотеках, реализующих всякие алгоритмы и обработки.
Рынок именно что компонентов для формошлёпства действительно был. А Python-то выстрелил не формошлёпством.
Там вроде речь шла не только о визуальных компонентах, а как раз "на все случаи жизни", но точно сказать не могу, давно дело было.
Да речь не о визуальных компонентах, а о просто библиотеках, реализующих всякие алгоритмы и обработки.
Я, кстати, ещё одну причину вспомнил, она вам должна понравиться :) Лицензия VB 5.0 Professional в 1997 стоила 500 баксов. Пайтон был бесплатным.
Вот всем хорош питончик, вот только оконный интерфейс к нему прикручивать надо каждый раз с плясками. А мне он часто бывает нужен. Вот жаль нету IDE где кнопочки от руки рисовать, а код на питоне к ним писать. Пляски с PyQT не в счет, как-то не зашло. Надо чтоб оно все вместе было - ткнул в кнопочку - тебя на ее обработчик в коде перекинуло.
Сравнивать вещи (в широком смысле) созданные в разное время просто не корректно. Автомобили не пробовали сравнивать? Все хорошо относительно к своему времени. Но это не значит, что все старое вдруг стало плохим и от него нужно срочно отказываться. Если работает, надёжно и простое, удовлетворяет необходимым потребностям, так пусть и работает. Так и со средствами разработки ПО: если с помощью известного программисту языка можно успешно и удобно разрабатывать софт, то для этого вовсе не обязательно искать какие-то новые инструменты. В "природе на все случаи жизни" одного языка программирования просто не существует, а главное и не нужно. Все определяет поставленная задача и для её решения сформулированные требования. Сегодня стал популярным Python, a завтра, будьте уверены, Alligator.
языки, ориентированные на удобство разработки и простоту чтения кода
Например, Perl
Ну да, ну да.
Дух BASIC жив.
Странно, что в статье о Бейсике нет никакого упоминания компилятора FreeBasic.
Такие мелочи могут показаться тривиальными, но стиль синтаксиса влияет на восприятие кода. В любом случае, если бы BASIC царил последние 40 лет, «язык программирования по умолчанию» имел бы совсем другой облик.
В своё время отказывался от любых предложений, связанных с разработкой на Pascal-подобных языках, из-за иррациональной аллергии на "begin/end" и объявлений переменных в начале scope
Понадобилось недавно запустить одну старую программу. 2012 года. Изначально была написана на VBA под автокад, потом переползла на VB.NET (ну так было проще, просто куски кода копировал). В новых версиях автокада не работает (там под каждую версию пересобирать надо. Библиотеки разные... Мда, VBA был удобнее). Пересобрать? Нее.. Хочет уже не .NET Framework, а .NET 8.0 и старше. Ага, ща её на C# переведу. В трёхсотых строках звереть начал - убрать всякие endif и next... Фигурные скобки поставить. В каждой строке точку с запятой... Круглые скобки на квадратные поменять... Плюнул. Скопировал файлы в новый проект, всё собралось. Пусть так и остаётся на VB.
А с нуля писать на барсике проще, всё студия подставляет и форматирует. Но я предпочту C# :-)
Ага, ща её на C# переведу. В трёхсотых строках звереть начал - убрать всякие endif и next... Фигурные скобки поставить. В каждой строке точку с запятой... Круглые скобки на квадратные поменять... Плюнул.
Коллега, на дворе 2025-й. Эту задачу быстро и без ошибок вам сделает даже чатгпт, не говоря уже про копайлот в Visual Studio
Принцип "что работало, работает и может работать дальше, а главное надежное и простое, то путь и работает" верен не только для обычного колеса, но и для всего остального, включая софт.
Очень странно, что в статье ни разу не упомянут язык программирования Lua.
Вот он как раз является современным аналогом Бейсика - простой человекочитаемый синтаксис (практически как по-английски), интерпретируемость, минимум конструкций, частое применение для написания игр.
Хотя у Lua есть специфика, связанная со встраиванием, он имхо сейчас наиболее близкий аналог языка Basic.
минимум конструкций
Вот это реально достоинство. В том же Python голову сломаешь всё упомнить, а если ещё свяжешься со сторонники библиотеками так без интернета вообще ничего не напишешь )) Но вот в школе ему обучают, и в комментариях куча положительных отзывов. Возможно в молодости воспринимается легче...
В brainfuck минимум конструкций, очень просто запомнить.
Шутка, повторённая дважды, уже не шутка. Слишком много внимания уделяется этой поделке на Хабре.
Доведение до абсурда - наше все. ;)
Ну минимум конструкций. И что? Не обязательно сразу помнить и использовать абсолютно все конструкции языка. Мне lua не зашел. Таблицы, из которых можно нужно выклеить все что угодно - забавно, как brainfuck но на максималках.
Точно так же не обязательно сразу погружаться в самые глубины метапрограммирования и тем самым делать из этих таблиц что угодно ужасное (например, а давайте наследование менять на ходу). Сравнение с brainfuckом имхо не уместно, механизм метатаблиц скорее "Всё должно быть сделано настолько просто, насколько это возможно, но не проще этого".
По мне так в Lua наоборот ряд вещей местами всё ещё "прибит гвоздями" и не позволяет его окончательно вывернуть "мехом внутрь" пусть даже он при этом станет выглядеть более похожим на brainfuck. При том что изначально и Lua и была неким DSL и языком для построения DSL, а не общим языком программирования.
Опять какая-то попытка воскресить древний неудобный язык для обучения. В чём проблема начинать сразу с python? Это и не сложно, и обычным школьникам, которые не пойдут в программисты, будет реально полезно. По крайней мере такие школьники в будущем вместо написания скриптов к таблицам на неудобном vba сделают это на проверенном openpyexcel, и таким образом поднимут где-нибудь офисную культуру. А вот изучение Basic и Pascal оставьте истфаку.
Да, на практике не профессионалам нужен или python или js, но у первого ленин-курва проще.
Это и не сложно, и обычным школьникам, которые не пойдут в программисты, будет реально полезно. По крайней мере такие школьники в будущем вместо написания скриптов к таблицам на неудобном vba сделают это на проверенном openpyexcel, и таким образом поднимут где-нибудь офисную культуру
Школьникам, которые не пойдут в программисты, будет необходимо установить python, pip, сам OpenPyxl, а самое главное - знать объектную модель VBA, чтобы хоть что-то написать.
Ну и нафига козе баян, если в Эксель есть под капотом сразу всё необходимое? Если можно на неудобном vba включить запись макроса и иметь минимальную автоматизацию практически без знаний программирования?
Я не знаком с python и OpenPyxl. Скажите, там можно по аналогии с VBE закинуть в окно Watches, например, переменную wb и, нажав на плюсик рядом с ней, получить все свойства и значения этих свойств с типами и контекстом для этого и всех вложенных объектов?
На мой взгляд OpenPyxl нужен, если нужно создавать/редактировать xlsx в автоматическом режиме без установки офисного пакета, т.е. на сервере. Но зачем это школьникам, которые не пойдут в программисты? Поднимать офисную культуру?
Я один из тех, кто в начале 2000ых лепил всякое на VB. Да, я уже тогда неплохо кодил на Си для железа. Но почему-то именно на VB удавалось очень быстро сбацать какую-нить тестовую прогу для проверки и отладки железки. Обычно это была форма с десятком кнопок, какие-нить логи и иногда графика. С аппаратурой работало через COM или через FTDI с ее библиотеками или иногда по локалке.
Пробовал я тогда и VC и Borland Builder - не зашло. Медленно и долго. Сильно позже, когда уже везде было .NET, а VisualStudio 6 перестало ставится на новые системы - я уже переполз на C#. А потом и вообще на Qt. Но о VB до сих пор приятные воспоминания. И некоторые самописные инструменты тех лет у меня до сих пор в ходу. Как ни странно все что писалось под XP - без проблем работает под десяткой даже без плясок с бубном.
В тексте куча немерянной хрени, например : "в первых версиях C даже не было булевого типа — выражения сравнения просто возвращали 1 или любое ненулевое (истина) или 0 (ложь). "
Специального булевского типа в Си не было 30 лет - с начала 1970-х до стандарта C99.
Ни в K&R не было, ни в ANSI C в 1989 году. В те времена bool делали через define, typedef и потом enum (с ANSI C 1989). Это не "первые версии".
Вы весь текст с помощью ChatGPT написали? Я сразу по заголовку догадался. Статьи с такими заголовками пишут с помощью LLM, которые там пургу гонят.
Программист на C должен сам управлять памятью, следить за указателями и учитывать массу нюансов, от переполнения буфера до арифметики указателей
В паскале программист занимается ровно тем же самым.
VB 5.0 был прекрасен в свое время для rapid development
Ну только если вы не владели Delphi :)
Delphi пришел позже и ненадолго, потому как смигрировал на линукс. Факт того, что продукт борланда сильнее и мощнее тогда был - неоспорим, но у VB был сильно ниже порог входа для меня 14-летнего :)
что продукт борланда сильнее и мощнее тогда был - неоспорим,
Как раз таки оспорим.
VLC была более обширной, целая гора элементов управления прямо из коробки. Но вот компилятор у Борланда генерировал более убогий машинный код — проверено. Линкер борландовский генерировал раздутые исполняемые файлы, не умею сливать секции импорта линкуемых объектников в один большой дескриптор импорта (с одной объединённой IAT/ILT) для каждой отдельно взятой импортируемой библиотеки).
VLC была более обширной, целая гора элементов управления прямо из коробки. Но вот компилятор у Борланда генерировал более убогий машинный код — проверено.
По сравнению с чем? Минуточку, мы не с Visual C++ сейчас сравниваем, а с Visual Basic :) Да, он там вам, вероятно, не хуже С++ оформит фрейм вызова подпрограммы, но на том всё и закончится. Как только речь зайдёт о связывании программы с библиотеками, VB будет куда более медленным.
По сравнению с чем?
Если этот вопрос относится к фразе «компилятор у Борланда генерировал более убогий машинный код», то ответ — по сравнению со здравым смыслом.
Я много раз в машинном коде, сгенерированном Борландом, замечал идеому в духе:
mov eax, dword [xxxxx]
mov ecx, eax
mov edx, ecx
mov eax, edx
; дальше используется eax, копии того же самого
; значения в регистрах ecx и edx тут же перезатираются чем-то ещёили
mov ecx, 0
mov eax, ecxвместо просто xor eax, eax
Microsoft-овский компилятор такими глупостями не страдал, а вот борландовский — да. Неужели никогда не замечали?
Да, он там вам, вероятно, не хуже С++ оформит фрейм вызова подпрограммы, но на том всё и закончится. Как только речь зайдёт о связывании программы с библиотеками, VB будет куда более медленным.
Это опять клевета на VB. С чего бы ему быть более медленным?
VB будет ровно настолько медленным, насколько вы его заставите. Если сама библиотека, с которой вы намерены работать, предлагает изначально медленный интерфейс взаимодействия, то взаимодействие через этот интерфейс будет естественно медленным. Но оно таким будет хоть из Delphi, хоть из C++.
То есть ли библиотека предполагает, что взаимодействовать с объектами можно только через позднее связывание (по терминологии COM) через IDispatch, то естественно это будет медленно: потому что нужно имена методов/свойств транслировать в DISPID, все аргументы упаковывать в VARIANT, если используются именованные аргументы — ещё их их dispid резолвить.
Если же вы работаете с библиотекой через вызовы по типу раннего связывания (по терминологии COM), то и код вызовов не будет «куда более медленным» (потому что с чего бы ради ему таким быть?), чем эквивалентный код на Delphi или на C++.
Либо если библиотека предлагает оба способа, но вы насильно со стороны VB-кода выбираете более медленный (но более гибкий) способ, то это будет медленнее, но это же были целиком вашим решением.
Я ещё раз предлагаю посмотреть на пример взаимодействия с Direct3D:
https://habr.com/ru/companies/ruvds/articles/971476/#comment_29219988
Какие излишества тут сгенерировал компилятор VB? В каком месте и за счёт чего Dephi или C++ обыграли бы его, сгенерировав более компактный и быстрый код?
В Delphi не было возможность стопнуться на брекпоинте и кардинально перекроить код процедуры, в которой вы остановились, убрав какие-то строки, добавив какие-то строки, поменяв какие-то строки местами, а затем продолжить выполнение с любого места. А в VB — было.
Также и работа с COM-объектами была менее удобной, если говорить о чужих COM-объектах, а написание своего COM-сервера или ActiveX-сервера тоже была более тяжёлой задачей на Delphi.
Увы, ничто не идеально в этом мире
а написание своего COM-сервера или ActiveX-сервера тоже была более тяжёлой задачей на Delphi.
Почему? Там это делалось просто "New ActiveX", и дальше просто как обычный элемент управления писать.
В Delphi не было возможность стопнуться на брекпоинте и кардинально перекроить код процедуры, в которой вы остановились, убрав какие-то строки, добавив какие-то строки, поменяв какие-то строки местами, а затем продолжить выполнение с любого места.
Не было, т.к. это всё-таки не интерпретатор :Р. Но зато была возможность мгновенно пересобрать программу и повторно запустить, чем не обладали другие компиляторы.
Там это делалось просто "New ActiveX", и дальше просто как обычный элемент управления писать.
Попробуйте написать на Delphi ActiveX-сервер с классом, экземпляр которого должен олицетворять математическое выражение или математическую функцию (от одного или нескольких переменны) и притворяться этой функцией, и чтобы это можно было использовать из скриптового языка, например из VBScript, примерно вот так:
Set math_func = CreateObject("HabrDiscussionServer.MathFunc")
math_func.Expression = "f(g,x) = (sin(g) + sqr(x)) / (g*x)"
a = math_func(1,2)
b = math_func(3.141, 25)Чтобы не тратить время и не смещать акцент на написание эвалюатора матвыражений, можете вообще не писать эту часть, а сделать заглушку, которая будет просто возвращать сумму всех аргументов вместо вычисления user-defined выражения. Вопрос не в том, где проще написать эвалюатор, а именно в ActiveX-специфичных вещах.
Сравним компактность и простоту реализаций на VB и на Delphi.
Не было, т.к. это всё-таки не интерпретатор :Р.
Так и VB IDE не интерпретировала исходный текст, а выполняла заранее скомпилированный байт-код, но при внесении правок в исходный код на живую в процессе выполнения перекраивала этот байт код, если это было в принципе осуществимо.
При желании авторы Delphi могли бы сделать такое же перекраивание машинного кода. Например, если я взял и вырезать строчку с вызовом функции в процессе пошаговой отладки программы, взять и заNOP-ить её на уровне машинного кода. Или если я что-то добавил, пропатчить код с помщью jmp и внести недостающие инструкции.
Попробуйте написать на Delphi ActiveX-сервер с классом, экземпляр которого должен олицетворять математическое выражение или математическую функцию
Согласен, это будет немного неудобно, надо будет перегрузить TAutoObject.Invoke, и ручками параметры обрабатывать, но с другой стороны, не так чтобы и сложно, десяток лишних строк кода. Наверное, на VB это будет банально красивее.
А сколько вам понадобится лишних строк кода, чтобы сделать на VB, например, веб-сервис?
При желании авторы Delphi могли бы сделать такое же перекраивание машинного кода.
Вопрос тут в производительности. В байт-коде не нужно пересчитывать все переходы внутри программы, поменял код - и исполняющая среда подхватила. А в машинном, ну хорошо, если только переходы. А если вы переменную добавили в выполняющейся подпрограмме в машинном коде - ещё и фрейм стека перестраивать, и всё над ним двигать?
В байт-коде не нужно пересчитывать все переходы внутри программы,
С чего это ради? Эти слова косвенно говорят о том, что вы не понимаете или неправильно понимаете то, как устроен P-код VBVM и его выполнение.
Точно так же, как и в машинном коде, в P-коде все условные и безусловные переходы внутри процедуры нужно пересчитывать, если что-то в ней перекраивалось. С P-кодом даже больше нужно сделать: если в x86-инструкциях условных и безусловных переходов операнд закодирован как относительное смещение целевого адреса (относительно начала следующей инструкции — следующей по отношению к Jxx), так что целый блок x86-инструкций можно двигать, и все Jxx инсрукции в нём будут position independant, если не ведут за пределы блока), что в P-code все jump destination указываются не относительно следующей инструкции, а относительно начала процедуры (первой P-code инструкции процедуры). И VB IDE всё это делает при перекраивании: пересчитывает, правит.
А если вы переменную добавили в выполняющейся подпрограмме в машинном коде - ещё и фрейм стека перестраивать, и всё над ним двигать?
Всё то же самое актуально и для P-кода. Виртуальная машина VB стековая, буквально для всех действий сначала нужно что-то положить на стек: для вычисления выражений, сколько угодно сложным бы оно ни было, операнды кладутся на стек а затем вызываются инструкции, соответствующие операциям (и результат после выполнения такой инструкции тоже остаётся на вершине стека), при вызове процедур параметры складываются на стек и так далее. При этом какой-то свой отдельный обособленный стек не используется. Используется основной стек = процессорный стек, с верхушкой в ESP.
И таким образом добавление новой локальной переменной в уже выполняющейся в данной момент процедуре потребовалало бы перекраивания фрейма для вклинивания туда новой локальной переменной.
И тем не менее, VB IDE позволяет остановиться прямо внутри процедуры, добавить несколько новых локальных переменных, вставив их объявления в код, и продолжить выполнение (помимо добавления новых переменных можно добавить и код, произвольным образом их использующий).
Делать это можно и в том числе, если, например, мы стопнулись внутри рекурсии на каком-нибудь 10-ом уровне вложенности. Так что у нас не только процедура «Test» прямо сейчас находится в середине своего выполнения, но и вызвана она из Test, а Test вызвана из Test — и так 10 уровней. И добавлять новые локальные переменные — можно. И они появятся в каждом фрейме этой рекурсии с 10 уровнями вложенности.
Для этого VB IDE не перекраивает стековый фрейм (или стековые фреймы, в случае с рекурсией). Всё гораздо проще. Для этого просто изначально в фрейме есть резервное место на случай добавления новых переменных в процессе отладки. Примерно 150 байт на случай, если внезапно захочется приостановить выполнение и понавставлять везде новых локальных переменных. Это очень большой запас: 30 с чем-то локальных переменных типа Long/String/Object/Single. Я ни разу при правке кода по живому не упирался в этот лимит: обычно за раз хочется добавить переменных никак не больше, чем пальцев на руке.
И в Delphi тоже так могли бы сделать. Сколько держать резерва на случай появления новых локальных переменных в процессе работы программы могли бы сделать кастомизируемым — для тех, у кого в планах запускать оргромные по вложенности рекурсии и есть опасение, что стека не хватит.
Вы ошибаетесь по поводу Pcode
Более подробно о Pcode Quick/Q/VB можно прочитать тут: qb.js: An implementation of QBASIC in Javascript
В Delphi не было возможность стопнуться на брекпоинте и кардинально перекроить код процедуры, в которой вы остановились, убрав какие-то строки, добавив какие-то строки, поменяв какие-то строки местами, а затем продолжить выполнение с любого места. А в VB — было.
Это поведение VB и доказывает что в нем был интерпретируемый Pcode. С откомпилированным кодом такие шутки не проходят и требуют перекомпиляции измененного сырка.
Это бессовестная манипуляция термином «интерпретируемым». Если вы можете себе позволить сказать, что процессор x86 интерпретирует свой машинный код, то да, у меня нет претензии к вашей фразе «интерпретирумый Pcode». Если же по вашему это неуместное употребление слова «интерепретирует», и правильно говорить, что процессор x86 выполняет свой машинный код, то я требую и в отношении Pcode говорить, что виртуальная машина его выполняет, а не интерпретирует.
del
Возможно, код большинства программ визуально выглядел бы более «словесным». Например, вместо for (int i=0; i<10; i++) { ... } писали что-то вроде FOR i = 0 TO 9 ... NEXT i. Сохранилась бы и традиция нечувствительных к регистру ключевых слов: Begin, BEGIN или begin— неважно.
Тем временем PL/SQL:
declare
l_result number;
begin
for i in reverse 1..10 loop
l_result := i * i;
if i = 5 then
l_result := l_result - 1;
end if;
dbms_output.put_line(i || ': ' || l_result);
end loop;
end;
А что было бы с другими языками программирования, если бы развивался, например, PL/I из 60'х или, ещё раньше, Fortran из 50'х ? А бы да ка-бы. Сама постановка такого вопроса не корректна и не профессиональна. Каждый ЯП создавался и создаётся для решения каких-то своих специализированных задач и потребностей текущего времени. Универсального ЯП "на все времена и все случаи жизни" просто быть не может, да и не нужно.
Что было бы, если BASIC развивался вместо C и Python