Где-то неэффекттивен, но улучшения предлагать надо с осторожностью. Вот я как-то думал, с высоты опыта, что могу улучшить кассетный формат без потери его устойчивости к искажениям сигнала. Казалось, что вся теория была "за". Однако практика показала, что формат FM по каким-то неведомым мне пока причинам обладает исключительной стойкостью к искажениям, достичь которой другим способом не удалось. И действительно, сегодня подобное кодирование применяется в радио-стандарте LoRa, где важна не скорость, а дальность передачи.Сообщение от SfS
И таких примеров много.
Быстрой - до момента достижения критической фрагментации памяти.
Текущую реализацию можно улучшить. Но с кучами на 8-битных архитектурах надо осторожнее. На них в свое время применялись другие, хорошо забытые, трюки - например, Gap Buffer. По сути тот же стек, но 2шт. Можно сделать и больше стеков, динамически их уплотнять и разуплотнять и т.д. В общем, не кучей единой, особенно, когда памяти мало. А еще все эти красивые вещи надо разработать на ассемблере и уместить в 16К ПЗУ.
Тут да, вероятнее всего, сказывается отсутствие интернета, соответствующей литературы, или банально времени у авторов.
Да. И при всем при этом они создали вполне неплохой бейсик. Они смогли. А мы не смогли, хотя и литературы валом, и знаний, и опыта. Мне приходит иногда идея: "А не запилить ли бейсик на современных технологиях для Спектрума?" Но дальше идеи дело не идет. А ты бы хотел запилить хороший, правильный бейсик?
- - - Добавлено - - -
Кое-какая проработка была, например, нереализованные команды MOVE, ERASE, CAT, FORMAT, и едва реализованная OPEN#. Тут причина только в том, что времени не хватило. Где-то пробегало даже интервью, где Синклер или разработчики его бейсика прямо говорили, почему не закончили подсистему ввода-вывода. Как есть - так есть.
Перехват обработчика - не такой уж и костыль. Если имеешь книгу Логана и О-Хары - то написать обработчик, добавляющий в бейсик новые команды, не так уж и сложно. С API было бы не проще, разве что только "стандартнее". Я как-то развлекался добавлением в бейсик новых команд, внося изменения в ПЗУ. Удалось органично встроиться в соответствующие процедуры, но каких-то больших преимуществ, по сравнению с написанием обрабочика, этот способ не имеет.
Более того, расширяемость некоторых библиотек на том и построена, что следует добавить в обработчик неизвестных библиотеке ситуаций свою часть для добавления функционала. Далеко ходить не надо - оконная система Windows использует этот способ.
Не знаю, кому не хватало. Неизменность ПЗУ за все время жизни компьютера - чем не стандартизированное API? Вызывай когда хочешь и что хочешь, а не нравится - не вызывай, пиши своё. С другой стороны, любое API всегда ломается при переходе на новую версию - даже в тех проектах (напр. Windows), где обратная совместимость возведена в ранг высших ценностей.
А в чем проблема выставить регистры? Параметры надо как-то передавать, и регистры - самый быстрый способ это сделать. Большинство подпрограмм ПЗУ (LOAD, SAVE, BEEP, PLOT, DRAW, калькулятор и мн. др.) были вполне себе изолированы и не требовали предстартовой подготовки.
Не факт, что именно из-за этого. В Spectrum +2 и Spectrum-128 в прошивку было внесено немало изменений, и никто не очканул. Возможно, дело было просто в деньгах. Зачем вкладывать деньги в исправление ошибок, если эти ошибки незначительны по своим последствиям и не влияют на популярность продукта и его продажи?
А универсальный принт, одинаково полезный для всех, не сделаешь. Одному покажется, что в принте мало функций; другому покажется, что он медленно работает; третьему хочется перетереть системные переменные, а без них принт не работает. Писали своё либо тогда, когда имеющееся не подходило, либо просто для развития.
Не позволило бы. Даже sprintf подходит не всегда и не всем, особенно, если нужно выжать последние крохи по быстродействию.
А потому, что идеология бейсика (не только на Спектруме) всегда была в том, чтобы останавливать программу при малейшей ошибке, а не продолжать ее выполнение, как к тому привыкли Сишники.
Кому-то это неудобно, зато обеспечивается полная проверка корректности программы во время исполнения. Я бы с удовольствием имел интерпретатор Си, который валится при любом Undefined Behavior. Для отладки и тестов бы использовал. Но такового нету.
Помню, что мои бейсик-программы тех времен были достаточно надежные, чтобы не вылетать по ошибкам. Неудобства доставляло только нажатие пользователем клавиши Break и ошибки ввода-вывода. Но для их перехвата были специальные средства. Кто хотел - тот имел.
Ошибка в том, что поступившая от пользователя команда - нарисовать нечто за пределами экрана - не может быть исполнена. Классический отказ. Падать в случае его возникновения допустимо. Особенно учитывая роль бейсика как обучающего языка. В мои времена все бейсики вели себя так.
Стандартных средств нет, но наколхозить свои было чрезвычайно легко, учитывая легкость перехвата RST 8. В журналах и других источниках была куча маленьких подпрограмм в кодах "ON ERROR GOTO", позволявшие обрабатывать ошибки. Но поверь, не нужно это было так уж сильно. Если программа написана надежно - в ней не будет возникать ошибок, она не будет падать. Не надо делить на нуль - и все будет в порядке. А написание обработчиков ошибок - что для новичков, что для профессионалов - трудная задача. Слишком многое надо предусматривать. И отлаживать программу с обработчиком ошибок тяжело. Вот зациклился твой обработчик - что делать? Жать ресет, а потом грузить все заново с кассеты? Такое себе удовольствие.
Я никогда не применял на спектрум-бейсике обработчики ошибок, хотя знал об их существовании и написал на бейсике пару простых игр и других нетривиальных проектов.
Скажу тебе как программист, использующий и реализующий различные численные методы в повседневной работе.
Не надо это. Я не встречал в серьезной литературе ни одного описания или реализации численного алгоритма, который бы полагался при нормальной работе всякие Inf и NaN.
Не всякая бесконечность равна другой. Это только на первый взгяд заманчиво вычесть из Inf 1000 и убедиться, что остается Inf. А если умножить ее на нуль? А если прибавить -Inf? Не все аспекты математической бесконечности удается реализовать с помощью значения "Inf". Поэтому на него и не полагаются.
Если при работе численного алгоритма возникают Inf, NaN, или просто очень большие числа - то это не означает ничего хорошего. Либо в реализации ошибка, либо недопустимые исходные данные. В таком случае, чем раньше ошибка будет обнаружена, а программа - остановлена, тем легче ее наладить. А не разбираться потом, на каком этапе вычислений произошло переполнение, и почему массив выходных данных заполнен NaN.
А отлаживать численные методы - поверь, трудная задача. Этому нельзя научиться по книжкам, обучающим просто программированию. Мне пришлось на опыте выработать ряд специальных приемов для такой отладки. Может быть, кто-то уже написал соответствующую книжку, но я таковых пока не встречал.
Как раз с неделю назад смотрел видео с критикой различных языков программирования, там отдельный раздел был посвящен "интуитивным" правилам сложения различных несовместимых типов в Javascript. Как то некоммутативность такого сложения и неочевидность, почему получился тот или иной результат. На мой взгяд, такие вещи не способствуют обучению начинающих.
Или казалось, что надо. Я как-то не встречал больших и красивых проектов на этих бейсиках. Правда, не искал специально.
Большие и красивые проекты создавались на ассемблере. А там нет проблем с остановом программ по ошибке. Есть только проблемы с перепахиванием памяти и наступлении сбоев, которые потом трудно отследить. Благо только, что не было Undefined Behavior, а то бы многие программисты были доведены до белой горячки.
Так, да не так. Во-первых, я привел выше возражения. Во-вторых, этот бейсик вполне неплохо работал. А в-третьих - что мешает сделать свой, хороший бейсик, с блекджеком и шл.?
Ответить с цитированием