А мне, повторяю, кажется, что дело в деньгах. Зачем тратить деньги на зарплату программистов и пилить новое ПЗУ, если старое работает, и все довольны? Лучшее - враг хорошего.Сообщение от SfS
Сколько-нибудь существенного улучшения бейсика добиться было невозможно. Бейсик-128 тому хороший пример. Когда захотели - то запилили еще 16К кода в ПЗУ. И часть старого поменяли, наплевав на несовместимость. А что улучшилось от этого? Если приходилось программировать на бейсике, имея 128й - то я предпочитал набрать usr0 и работать со старым бейсиком. Он был и удобнее, и надежнее, и новые функции 128го бейсика того не стоили.
А что ошибки "неисправимы" - то их там было кот наплакал. Не было из-за них критичного нарушения функционала. Находили их по большей части энтузиасты, вроде Яна Логана и О-Хары. Простому человеку на них наткнуться было очень маловероятно. В современных продуктах ошибки такого уровня могут быть известны, но никогда не исправляться. Даже если идет постоянная разработка новых версий, и обратная совместимость не важна. Потому, что есть более приоритетные задачи. Например, более серьезные ошибки или добавление функционала.
Я думаю, не решил бы. Всегда нашелся бы какой-нибудь умник, вызывающий напрямую какие-то процедуры, не вошедшие в "пул системных вызовов". Ну или пул менялся бы от версии к версии. Подобные меры способствуют совместимости новых версий библиотек со старыми, но не решают эту проблему полностью.
А толку от этого? Можно ли взять бинарник со старого Linux с совместимой архитектурой процессора, и запустить его на новой версии ОС? У Линукса проблемы совместимости старого софта с новыми версиями ОС огромные. Как там у коммерческих UNIX - не знаю, может, ты в курсе?
А под линуксом - бинарники не запускаются, а собирать проекты заново из исходников - длительное, требующее высокой квалификации и опыта, и рискованное дело. Не всегда удаётся. То одна ошибка компиляции, то другая. То одна библиотека не подходит, то другая. То в компиляторе что-то поменялось.
"Очень резко" - это как? Бейсик что, перестает от этого быть полным по Тьюрингу? Если программа написана без ошибок - то она не вызовет отказ и останов. В этом и цель программирования. Написать программу, которая решает некоторую задачу и при этом не сбивается.
В том, чтобы научить составлять надежные программы. В которых нет ошибок, которые кому-то хотелось бы "замести под ковёр". Чтобы программа была точно выверенной и в любых ситуациях не выходила за пределы заданных рамок.
Я понимаю, тебе очень не хватало клиппинга графики. Сочувствую.
А мне вот приходилось работать с другими бейсиками, где команды CIRCLE вообще не было. И знаний не хватало сделать свою реализацию на том же бейсике. Ну или тормозно это было. И ничего. Все равно программирование доставляло массу удовольствия и развития. Можно было реализовать массу других проектов. И без кругов (тем более - обрезанных) рисовалась прекрасная графика на экране.
Использовал даже бейсики, где вообще графики не было. РК-86 и "Агат". На последнем была некоторая графика... CIRCLE не было, но не это было основной проблемой. Основной было то, что в графическом режиме не было вывода текста! Нарисуешь, к примеру, график функции - а чем подписать оси?
Мы говорим про перехват ошибок. Начинающие обычно таким не заморачиваются - им бы хоть как-то держать равновесие в написании простейших программ. Не нужен им перехват ошибок.
Когда же обучающийся достигает такого уровня, что ему хочется и можется написать обработчик ошибок - тогда же он становится способен найти "колхозные" решения этой задачи в виде распространяемых через журналы или друзей маленьких подпрограмм в машинных кодах.
Перехват ошибок штатно имеется в некоторых бейсиках, например, бейсик-Агат (ONERR GOTO). Я стал играться с этим далеко не на первом году своего знакомства с бейсиком. И к тому времени я уже был в состоянии находить и использовать полезные подпрограммы в маш. кодах.
Не понимаю, зачем тебе все время хочется заниматься обработкой ошибок? Это же трудно и громоздко, и не способствует достижению основных целей программы, которую ты взялся писать.
Меня тема обработки ошибок интересует только как раздражитель. Как необходимое зло, которым приходится заниматься. Но, если можно этого избежать - то предпочитаю избежать. Особенно, если пишу программу-прототип для внутреннего применения - тогда лучше, чтобы она исполнялась на таком же чувствительном интерпретаторе, как бейсик, чтобы при первых признаках неполадок останавливалась. Тогда ее легче отлаживать.
Это же лишние трудозатраты. Проверить результат на выход за пределы допустимого диапазона. Вывести сообщение, предложить что-то поменять. Когда ты начинаешь писать и отлаживать какой-нибудь вычислительный алгоритм - то такая деятельность только отвлекает и повышает затраты времени и сил. Их лучше тратить на сам алгоритм. А обработкой ошибок пусть лучше занимается интерпретатор. Его задача - обнаружить сбой на возможно ранней стадии. И остановить программу, облегчая тем самым ее отладку.
А проверять лучше не результаты - они не всегда будут явно ошибочными. Лучше проверять исходные данные на допустимый диапазон.
И опять же, в предложенном тобой решении неверные (Inf/NaN) промежуточные результаты идут куда-то дальше по программе, которая к этому не готова и может забрести в страшные дебри. И отследить, где возник первый сбой, становится гораздо труднее. До результатов можно и вовсе не добраться. Какой-нибудь итерационный алгоритм может вообще зациклиться.
Не знаю, какие ты писал и налаживал вычислительные алгоритмы, что тебе оказалась предпочтительной такая логика? Я на бейсике писал, в числе прочего, численное интегрирование, интерполяцию, метод Гаусса, приближение методом наименьших квадратов... У нас целый курс лабораборок по численным методам на бейсике был. Никогда не было такого, чтобы огромной величины (на грани переполнения) числа возникали там при нормальной работе. Никогда не получал сообщения об ошибке при переполнении. Ошибки были другие. А из какого опыта берутся твои предпочтения?
На стандартном есть. Игры есть, даже динамические ("Breakout", "Ground force zero", "Dictator"). Всякие гороскопы, нумерология и др.
Ответить с цитированием