128 basic

[Dart Alver]

да что вы все так к черепашьей графике привязались, набор стандартных процедур вообще не главное в языке
главное - уровень абстракции и структурность

Так я и говорю :

По ходу logo не повезло с пиаром.

Logo изначально выпячивали чепашью графику, а всё остальное как бы и не смогли пропиарить. Вот и результат - за ним закрепилась слава детского языка, его мало использовали тогда, а сейчас при засилии питонов, перлов, луа и т.д. тем более. Ну и думается что интерпретатор линейного бейсика был проще и занимал меньше места чем интерпретатор структурированного языка с кучей абстракций, вот бейсик и прилип к пзу тогдашних компов.

[Lethargeek]

Ну и думается что интерпретатор линейного бейсика был проще и занимал меньше места чем интерпретатор структурированного языка с кучей абстракций, вот бейсик и прилип к пзу тогдашних компов.

в том и дело, что его по инерции тащили с прошлого поколения
грубо говоря, фокал ~4-6k, классический бейсик ~6-8k
а доступно уже было намного больше

[Spectramine]

Это как? Примеры тормознутого кода есть?
Не каждому дано написать тормозной код на ассемблере? Только программисты высокой квалификации могут заставить тупить прогу в машкоде?
По-моему, правильно сказать, что обычный программист выдаст код, который вполне хорош по быстродействию. Асы могут получить код, который работает быстрее - за счет просто более оптимального кода без изменения алгоритма, который применяли для решения задачи. Или значительно быстрее - уже с изменением примененного алгоритма.
Но вот тормознутый код на ассемблере - это надо постараться.

Самый простой пример - использование RST #10 при выводе знакоместа для динамической графики. Или процедур калькулятора Бейсика для обсчета 3d. Или процедур ПЗУ для рисования динамического 3d - а ведь они написаны на ассемблере.
Побитный скроллер на Спектруме это почти всегда тормоза, если это не бегущая строка, а более-менее значительная часть экрана.
Да и познакоместный на весь экран может быть тормозным - можете оценить в игре Quazatron, например.
Графическая заливка на Спектруме - тормоза.
3d на Спектруме это тоже почти гарантированные тормоза, особенно с заливкой, пример - Total Eclipse и Elite, когда на экране одновременно несколько объектов. ИИ на Спектруме это тормоза. Вообще любая работа с большими массивами данных, даже спрайтовая графика с крупными спрайтами.

Любой, кто писал на ассемблере что-то более-менее сложное, знает, что вера в бесконечность быстроты ассемблера очень быстро разрушается.

[Lethargeek]

Любой, кто писал на ассемблере что-то более-менее сложное, знает, что вера в бесконечность быстроты ассемблера очень быстро разрушается.

только вот то, что тормозит на асме при не слишком сильном старании, на интерпретаторах вообще будет спать, как ни бейся

[Spectramine]

только вот то, что тормозит на асме при не слишком сильном старании, на интерпретаторах вообще будет спать, как ни бейся

Естественно, а как иначе?

- - - Добавлено - - -

главное - уровень абстракции и структурность

Уровни абстракции и структурность это для более высокого уровня программирования, для начального вхождения в программирование Бейсик с его номерами строк идеален. Он также отличная подготовка к изучению ассемблера. А уровни абстракции и структурность - это для продвинутого программирования объемных программ. Возможно, поэтому Бейсик и обошел Лого в популярности.

[vlad-kras]

Самый простой пример - использование RST #10 при выводе знакоместа для динамической графики. Или процедур калькулятора Бейсика для обсчета 3d. Или процедур ПЗУ для рисования динамического 3d - а ведь они написаны на ассемблере.

Но как-то (сносно) это работает, играть можно, даже если используются неоптимальные процедуры из ПЗУ? Или прямо каждая игра по скорости отрисовка - как "борщ" на 3.5 МГц ?

Побитный скроллер на Спектруме это почти всегда тормоза, если это не бегущая строка, а более-менее значительная часть экрана.

Уперлись в ограничения аппаратной платформы? Логично, что 3.5 МГц значительно медленнее, чем 28. Но ведь куча игр вполне динамичны. А если не использовать более-менее значительную часть экрана, а использовать какое-то не очень большой число спрайтов, все же тогда по скорости нормализуется?

Да и познакоместный на весь экран может быть тормозным - можете оценить в игре Quazatron, например.

А можно ли там быстрей сделать?

Графическая заливка на Спектруме - тормоза.
3d на Спектруме это тоже почти гарантированные тормоза, особенно с заливкой, пример - Total Eclipse и Elite, когда на экране одновременно несколько объектов.

Трехмерки с заливкой. Тут опять же уперлись в ограничение по скорости - ничего удивительного. Про трехмерки с каркасными моделями не помню, там может получше.

Любой, кто писал на ассемблере что-то более-менее сложное, знает, что вера в бесконечность быстроты ассемблера очень быстро разрушается.

А вот с этим утверждением согласен полностью. Ассемблер быстрый, но не бесконечно быстрый. Только этого утверждения в начальном варианте я не увидел, а увидел другое - бейсик тормозной и ассемблер тоже тормозной.

[Advertiser]

[Spectramine]

Между

бейсик тормозной и ассемблер тоже тормозной.

и

Да и написать тормозной код вполне можно и на ассемблере, зависит от задачи и навыков программиста.

все же, мне кажется, есть разница.

Но как-то (сносно) это работает, играть можно, даже если используются неоптимальные процедуры из ПЗУ? Или прямо каждая игра по скорости отрисовка - как "борщ" на 3.5 МГц ?

Нет, сносно это не работает. Это может быть использовано только для вывода текста, когда спешить некуда, примитивных игр типа Питон с минимумом перестроения экрана, и построения статических изображений в текстовых играх.

Уперлись в ограничения аппаратной платформы? Логично, что 3.5 МГц значительно медленнее, чем 28. Но ведь куча игр вполне динамичны. А если не использовать более-менее значительную часть экрана, а использовать какое-то не очень большой число спрайтов, все же тогда по скорости нормализуется?

Всегда можно что-то оптимизировать, я привел примеры тормозного кода на ассемблере, когда решение задачи в лоб приводит к тормозам.

А можно ли там быстрей сделать?

Скорее всего да. Это тоже был пример тормозного кода на ассемблере.

[CPLx]

Всегда можно что-то оптимизировать, я привел примеры тормозного кода на ассемблере, когда решение задачи в лоб приводит к тормозам.

Я не думаю что печать символов там решена влоб, иначе работала бы быстрее. Обычно когда я вижу жуткие тормоза, то именно потому что задача решена не влоб, а с помощью какой-то сложной "программной инженерии", "современных паттернов проектирования", "последних технологий из computer science" и тому подобного. Потом я делаю решение влоб, оно работает в разы быстрее, а я сижу ломаю голову как можно было сделать так медленно. Это не только Спектрума касается, я это постоянно на PC вижу.
Чтобы ассемблер тормозил это надо либо использовать неэффективный алгоритм (и тогда это вообще не проблема языка - на бейсике будет еще медленнее), либо маяться дурью со всякими паттернами и прочим бредом.

[Lethargeek]

Уровни абстракции и структурность это для более высокого уровня программирования, для начального вхождения в программирование Бейсик с его номерами строк идеален.

ну это примерно как сказать: "печать символа в координатах это для более высокого уровня программирования, а для начального вхождения рисование каждой буковки попиксельно по физическим экранным адресам идеально"

- - - Добавлено - - -

Чтобы ассемблер тормозил это надо

...такты уметь считать

[Spectramine]

Это не только Спектрума касается, я это постоянно на PC вижу.

Скорее, это только PC и касается. Решение в лоб может быть эффективным, а может быть неэффективным. Но если оно неэффективно, приходится его оптимизировать.

сложной "программной инженерии", "современных паттернов проектирования", "последних технологий из computer science" и тому подобного

Любой инструмент имеет свою сферу применения. Современные паттерны проектирования и технологии призваны, в первую очередь, помогать справляться с возрастающей сложностью проектов. Сложные задачи в лоб вообще не решаются.

Я не думаю что печать символов там решена влоб, иначе работала бы быстрее.

Не знаю, о чем именно вы здесь, если о коде RST #10 ПЗУ Спектрума, то там код слишком универсален, использует абстракции каналов и потоков, и естественно в связи с этим намного медленнее специализированного и оптимизированного кода вывода знакоместа на экран в играх.

Чтобы ассемблер тормозил это надо либо использовать неэффективный алгоритм (и тогда это вообще не проблема языка - на бейсике будет еще медленнее), либо маяться дурью со всякими паттернами и прочим бредом.

Чтобы ассемблер тормозил, достаточно взяться за задачу, решение которой будет упираться в ограничения железа. Либо использовать неэффективный для выбранной задачи алгоритм, либо неэффективные наработки, либо неэффективные для данной задачи высокоуровневые абстракции. И конечно же это вообще не проблема языка ассемблера, который в принципе теоретически может дать максимально эффективные для данного железа программы, это проблема квалификации программиста либо сложности решаемой задачи. Проблемы языка ассемблера другие - низкая скорость и высокая трудоемкость разработки, низкий уровень абстракций, слабая читабельность программ, непереносимость или плохая переносимость кода на другие платформы.

- - - Добавлено - - -

ну это примерно как сказать: "печать символа в координатах это для более высокого уровня программирования, а для начального вхождения рисование каждой буковки попиксельно по физическим экранным адресам идеально"

Нет, это совсем другое. Любой изучение нового предмета делается от простого к сложному, если сразу взяться за сложное, можно просто не осилить порог вхождения, посчитать, что это не для меня и т.п. Вот Бейсик с его пронумерованными операторами - это просто, ему можно сопоставить простейшие бытовые алгоритмы с пронумерованными действиями. А структуризация и т.п. - это сложно, это уже когда ты разобрался с базовыми понятиями и начинаешь понимать, что их недостаточно. Даже Бейсик никто не начинает изучать с процедур, массивов и циклов, начинают с простых операторов, литералов и переменных.

- - - Добавлено - - -

ну это примерно как сказать: "печать символа в координатах это для более высокого уровня программирования, а для начального вхождения рисование каждой буковки попиксельно по физическим экранным адресам идеально"

Это скорее примерно как сказать "печать символа в координатах это для более высокого уровня программирования, а для начального идеально простая печать символа в текущей позиции вывода".