Подскажите пожалуйста, На каких языках пишутся игры.

[skyther]

Терзают смутные сомнения, что тут БК сам с собой разговаривает...

[Lethargeek]

что тогда задает стиль программирования, ассемблер или макросы?

Возможности, в нем заложенные

Или мы ожидаем, что начинающий в ассемблере и программировании вообще сразу сможет создать макросы, которые превратят ассемблер в структурный язык?

Сразу-то нахрен?

И что, от этого что-то меняется? От этого паскаль перестает быть структурным языком программирования?

Паскаль в очумелых ручках привыкших к бейсику вмиг перестает быть структурным без всяких GOTO

Или ассемблер становится им?

Стал уже давно

Желающий понять - поймет, желающий спорить - сделает вид, что не понял.

А сморозивший - прикроется высокопарными фразами

Нет, это был именно +2, там к системному разъему был подключен контроллер TR-DOS и теневое ОЗУ.

Вот я и спрашиваю: ну при чем тут Спектрум? Внешние железки, чтобы что-то скомпилировать (а то и чтоб запустить)
Твой паскаль умеет компилировать полноценные программы для работы на обычном Спеке БЕЗ наворотов?
Впрочем, даже в этом случае лучше подыскать песюковый кросс-компилер

Совместимость полностью сохранилась на уровне Спека +2 с дисковым интерфейсом. Теневое ОЗУ включалось по записи в определенный порт

...и Спек в CP/M режиме переставал быть Спеком, что и требовалось доказать

И что? От этого перестало быть возможным написать интересную игру на спековском бейсике?

Ту же самую? Нет, не перестало

Зачем что было нужно? Ты о чем вообще?

*терпеливо* Да о том же, что ты очень сильно переоцениваешь

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

в отрыве от современности

Численные методы - это один из примеров сложных алгоритмов, которые лучше всего поддаются отладке на интерпретируемых языках, желательно - со встроенными графическими средствами

И еще желательней - не на Спектруме

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

Fgsfds... это к чему вообще? Предлагаешь начинающим начинать с отладки сложных алгоритмов?

В играх (не демах) встречаются сложные алгоритмы, например, для реализации интеллекта "врагов". Их немыслимо отладить изначально на ассемблере.

После бейсика очень многое кажется НЕМЫСЛИМЫМ

Бейсик удовлетворяет ответу на оба поставленных вопроса - это во-первых.

Отрицательному - это во-вторых

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

Не вали с больной головы на здоровую
Это ты здесь начал плакать о косинусах и высасывать из пальца мнимые мегатрудности

[Lethargeek]

Терзают смутные сомнения, что тут БК сам с собой разговаривает...

Юлик, ТЫ?!

[psb]

Ибо явный баг, коим даже примитивные калькуляторы не страдают.

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

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

[null_device]

Меня вообще удивляет, как можно шесть страниц "меряться сингулярностями" и "жонглировать какашками"?! Было произнесено много "громких" слов, перечисленна масса "доводов" в пользу "верного и единственного" подхода в програмировании. Из всего этого, полезного, для себя я не увидел. Извиняюсь за копипасту, но, по-существу..

Скрытый текст

процесс работы компьютера заключается в выполнении программы, то есть набора вполне определённых команд во вполне определённом порядке. Машинный вид команды, состоящий из нулей и единиц, указывает, какое именно действие должен выполнить центральный процессор. Значит, чтобы задать компьютеру последовательность действий, которые он должен выполнить, нужно задать последовательность двоичных кодов соответствующих команд. Программы в машинных кодах состоят из тысячи команд. Писать такие программы - занятие сложное и утомительное. Программист должен помнить комбинацию нулей и единиц двоичного кода каждой программы, а также двоичные коды адресов данных, используемых при её выполнении. Гораздо проще написать программу на каком-нибудь языке, более близком к естественному человеческому языку, а работу по переводу этой программы в машинные коды поручить компьютеру. Так возникли языки, предназначенные специально для написания программ, - языки программирования.

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

Всё множество языков программирования можно разделить на две группы: языки низкого уровня и языки высокого уровня.

К языкам низкого уровня относятся языки ассемблера (от англ. to assemble - собирать, компоновать). В языке ассемблера используются символьные обозначения команд, которые легко понятны и быстро запоминаются. Вместо последовательности двоичных кодов команд записываются их символьные обозначения, а вместо двоичных адресов данных, используемых при выполнении команды, - символьные имена этих данных, выбранные программистом. Иногда язык ассемблера называют мнемокодом или автокодом.

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

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

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

[свернуть]

Каждый сам выбирает - строить ли ему "конуру из бетонных блоков" или "вырезать дом в скале"..

[Lethargeek]

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

Бугога! Стало быть, явная ошибка в первом же знаке после запятой при расчетах с внутренним двоичным представлением вещественных чисел это "глобальная фича"? Математику здесь нужно явно учить тебе

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

Поищи по форуму, все лежит, что счел нужным выложить
Кстати, как насчет твоих поделок на синклер-бейсике?
Только не забудь убрать из них расово неверный инпут с инкеем

Извиняюсь за копипасту, но, по-существу..

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

[Vadim]

На ассемблере все-таки писать сложнее по следующим причинам:

Отвечаю, хоть и несколько запоздало (у вас тут дискуссия уже далеко зашла). По Вашим, Barmaley_m, ответам вижу полное непонимание написания программы на ассемблере. Все время проекция оного с метода написания на бейсике. Я ж написал, что принцип одинаков. Но нельзя понимать это буквально. Одинаков подход к написанию, но методы отладки и использования дополнительных процедур разные. Итак, по порядку:

На ассемблере все-таки писать сложнее по следующим причинам:
1) Ошибки в программах имеют тяжелые последствия, вплоть до сброса компьютера. Раньше, когда программы сохранялись на кассетах, это серьезно задерживало процесс, пока перемотаешь кассету и загрузишь заново ассемблер
/skip/skip/skip///
То же касается компиляторов: ошибки в компилированных программах часто приводят к сбросу компьютера.

Во первых, я не имел ввиду написание программы на асме в магнитофонном варианте, хотя и так я писал года до 1994-го. В Gens3 потом в 4-м. И ещё в Zeus. Сохранял на кассету текст перед компиляцией и запуском. Да. Думать приходилось сильнее, а не тут же жать на кнопку запуска. Я далее это поясню.

2) Невозможно остановить в любой момент ассемблерную программу и посмотреть ее состояние с той же легкостью, как это можно сделать с бейсик-программой.

Совершенно несогласен. Во первых, в отладчиках (под которыми предполагается отлаживать программу которую мы пишем) есть режим эмуляции кода. Есть точки останова. Хотя я в 1992-1994гг ими не пользовался, а пользовался (как тут уже писали) монитором прошивки "турбо-90", вывел себе проводок от 17-й ноги Z80 и быстро проводил проводком по радиатору БП. Комп вылетал в монитор. Вот вам и прерывание. Да, иногда все напрочь висло (о этом случае я писал в Ревюшке'93), но это не смертельно. А вот с бейсиком беда. остановить его мы можем (хотя используя несложный прием мы это можем отключить), но как посмотреть состояние программы? Нужно проверять значения всех переменных (глобальных) вводя кучу команд... Сложнее чем в отладчике.

3) Некоторые ошибки в программах на ассемблере поздно себя проявляют, делая трудным их обнаружение.

Вот тут вообще не понял. С моей т.з. в этом отношении и бейсик и асм одинаковы. Ведь как пишется программа? Мы продумываем структуру, блоки, их взаимосвязь, а потом уже начинаем реализовывать задуманное. Грубо говоря приводя программу к структурированному виду, когда вся программа это иерархическая система "черных ящиков". У каждого ящика есть вход и выход. Нам надо реализовать функционал, потом о реализации можно забыть. Важно что бы ящик делал то, что нам надо. Делаем "внутренности" раскладывая сложные алгоритмы в набор более простых, вернее пишется скорее всего наоборот (уже когда структура программы проработана) пишем сначала базовые процедурки, потом на их основе более сложные и т.д. В бейсике процесс написания абсолютно аналогичен. И в паскале также. Предвижу возражения, что дескать "мы так не писали, писали как получится". В том то и дело, что если делать так, то ничего серьезного не напишешь. Это обычная тактика новичков, кто учится программировать. Бейсик для этого и предназначен, но и на нем можно писать так как я описал выше.

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

Тут согласен, но отчасти. Разборщик выражений в бейсике логической ошибки в программе не увидит и будет сидеть начинающий проггер и тупить над программой, а ошибка может быть и в алгоритме вычислений и в логике, да где угодно. А в асме без библиотки арифметических функций делать нечего. Нужен набор процедур, или самописный (что лучше всего, сначала писать их, учить асм, учить команды проца) или чей-то. Здесь ещё хочу сказать, что нужны базовые знания по программированию, в области арифметики. Т.е. точное представление двоичной и шестнадцатеричных систем исчисление, представлять себе деление, вычитание, сравнение, умножение, деление чисел. Знать алгоритмы быстрого деления и умножения сдвигом. В бейсике это не нужно, но знать программисту это всё равно надо. Такое мое мнение.

5) Отсутствие процедур ввода и вывода.Использование бейсиковских процедур требует изучения и понимания куда более сложных вещей, чем то, как пользоваться операторами PRINT и INPUT.

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

Можно пользоваться подпрограммами ZX-Basic, или опять же иметь свои наработки. Это полезней со всех сторон. Необходимо понимать как работает машина. Начинающие писать на бейсике этого сознательно лишаются. Они изучают некую абстрактную бейсик-машину. Со своим экраном, клавой и памятью в виде переменных и массивов. С одной стороны в этом и был смысл бейсика, абстрагировать обучающихся от железа, что бы они учили процедурное программирование. Но в этом и грабли на будущее. Т.е. зацикливаться на чем то одном не надо. Пописал человек 2-3 месяца на бейсике, более-менее изучил его и надо двигаться далее. Изучать в первую очередь архитектуру машины, основы программирования на асме (то что я выше описывал) и примерно через полгода уже можно приступать к написанию первых процедур. И уже позднее программ. Т.е. смысл сказанного мной таков. Имея знания о архитектуре компа, имея опыт написания программ процесс написания на бейсике и на асме будет похож. Примерно как снимать очень дорогой камерой изменяя и контролируя несколько десятков параметров и телефоном, нажимая на одну кнопку. Получаем и соотв. результаты.
Нужно не только изучать сам бейсик или асм, а изучать программирование, архитектуры проца, конкретной машины, видоподсистемы. Представлять себе как можно реализовать алгоритмически аркадную игру (типа Exolon, R-Type, River Raid, Crazy Cars). Как написать движок. И уже потом можно браться за инструмент. Бейсик, Паскаль, Си или асм. Есть примеры игр совершенно другого плана, изометрия, 3D (Dark Side и прочие), адвентюры с графикой и без и т.д. И каждый тип имеет свой движок, свои особенности. Не зная их, не понимая даже при идеальном знании Паскаля или Си игру не напишешь. Поэтому вопрос заданный в теме мне не понятен. Вернее понятен, что автор некорректно поставил вопрос из-за не понимания вопросы программирования игр вообще.

А ещё хотелось бы сказать, что проблемы освоения асма, паксаля или Си возникали ранее у тех, кто начинал с бейсика из-за скомканности обучения всему что связано с компьютерами. То кидаются в сторону алгоритмов, то учим бейсик, то устройство компа обзорно. В этом проблема. Масса отрывочных сведений, мало связанных между собой. Человеку который видит это всё впервые сложно усвоить всю инфу и адекватно её воспринять. Однобокое, неполное понимание в дальнейшем создает проблемы. Некоторые люди в упор не воспринимают hex числа, при том пишут программы на асме. Вот вам привет из zx-бейсике (в других реализациях бейсика hex числа есть). Т.е. если изучать всё планомерно и последовательно, что из себя представляет компьютер и с чем его едят, то и проблем будет меньше.

[psb]

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

бред несешь. разберись вот как раз с "внутренним двоичным представлением вещественных чисел".

Поищи по форуму, все лежит, что счел нужным выложить

мы разговариваем не по форуму, а конкретно в этой теме, выложи ссылки на свой софт. или ты слить решил по тихому?

По Вашим ответам вижу полное непонимание написания программы на ассемблере.

забавно это читать тов. Barmaley_m более чем в адеквате и про асм знает не по наслышке просто рассуждает не только смотря на свой личный опыт.

остановить его мы можем (хотя используя несложный прием мы это можем отключить), но как посмотреть состояние программы? Нужно проверять значения всех переменных (глобальных) вводя кучу команд... Сложнее чем в отладчике.

вводя команды типа LIST, PRINT, ты нажимаешь несколько кнопок. для того чтобы в отладчике посмотреть содержимое памяти или код, ты точно так же нажимаешь несколько кнопок.
только вот досада: хочешь ты посмотреть переменные A,B,C и строку D$, в бейсике ты так и пишешь: PRINT A,B,C,D$ - получаешь значение переменных в остановленный момент. а что ты делаешь в асме? для начала тебе надо знать адрес твоих переменных. где ты его берешь? ищешь кусок кода с этим адресом? или наугад среди кучи данных (по т.н. eyecatcher), зная что вслед за чем лежит? или открываешь листинг асма и ищешь там свою переменную? не слишком ли???
далее, нашел ты переменную, 2 байта, а там D5 38. ЭТО СКОЛЬКО???
вы будете дальше настаивать на удобстве дебаггера??

Ведь как пишется программа? Мы продумываем структуру, блоки, их взаимосвязь, а потом уже начинаем реализовывать задуманное. Грубо говоря приводя программу к структурированному виду, когда вся программа это иерархическая система "черных ящиков".

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

А в асме без библиотки арифметических функций делать нечего. Нужен набор процедур, или самописный (что лучше всего, сначала писать их, учить асм, учить команды проца) или чей-то.

правильно! новичку их сначала тока надо где-то взять, потом РАЗОБРАТЬСЯ как их использовать (это для вас сейчас это просто!), а потом юзать.
а писать такое новичку - да большинство нахрен пошлет программирование сразу, т.к. результата не будет ну очень долгое время.

Т.е. точное представление двоичной и шестнадцатеричных систем исчисление, представлять себе деление, вычитание, сравнение, умножение, деление чисел. Знать алгоритмы быстрого деления и умножения сдвигом.

это ты хочешь предложить новичку?)))) я подозреваю что этого даже монстр асма Lethargeek не знает... бейсик (и любой алгоритмический язык) тем и хорош, что ты заморачиваешься только с алгоритмом, но не с борьбой с машиной.
нехватку регистров в асме уже никто не помнит? память короткая? ах да, у Lethargeek особый ламерский метод складывать все в память...

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

нет здесь граблей. направления в программировании бывают разные и не стоит всех заставлять проходить свой путь. если ты системщик - тебе полезно знать то, о чем ты пишешь - алгоритмы деления, умножения, как работает комп. если же ты прикладник - в гробу видал все эти премудрости, твоя задача - решать поставленную задачу ЛЮБЫМИ методами. есть невероятное количество людей, никогда не изучавших асм, но делающих такие вещи, которые мы тут все вместе взятые можем не асилить. само по себе программирование - ничто и никому не нужно, оно становится значимым только в применении к какой-то области. и именно программированию учиться лучше точно не на асме. асм нынче вообще мало кому нужен.

Пописал человек 2-3 месяца на бейсике, более-менее изучил его и надо двигаться далее. Изучать в первую очередь архитектуру машины, основы программирования на асме (то что я выше описывал) и примерно через полгода уже можно приступать к написанию первых процедур. И уже позднее программ.

вот здесь вряд ли бы кто стал спорить, все верно.

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

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

Т.е. если изучать все планомерно и последовательно, что из себя представляет компьютер и с чем его едят, то и проблем будет меньше.

если писать все на асме, максимально продумывая, то винда и все остальное будет просто летать, даже на древних компах! и не глючить! ибо писавший будет досконально знать что и как он сделал. хехе но в реальном мире - это УТОПИЯ! это не реально ни на 0.001%. просто жизни не хватит и людей.

[Lethargeek]

бред несешь. разберись вот как раз с "внутренним двоичным представлением вещественных чисел".

Лол, с каким? С тем, в котором 1/2<>0.5? Уймись уже, балаболка!
Или мне тебе напомнить алгоритм деления в столбик для первоклашек?
Чтобы ты сумел поделить пятерку на десятку в двоичном коде
сосчитав на пальцах, сколько битов нужно для вычислений

мы разговариваем не по форуму, а конкретно в этой теме, выложи ссылки на свой софт. или ты слить решил по тихому?

Ты УЖЕ слил по-тихому, даже слова не сказав о своих поделках на бейсике

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

Лично я обычно нажимаю Step или Step Over и вижу все
Кстати, как на бейсике организовать обычную трассировку?
Или как следить за ходом прорисовки, не потеряв саму прорисовку?
Будешь дальше настаивать на удобстве отладки ручками под бейсиком?

вот досада: хочешь ты посмотреть переменные A,B,C и строку D$, в бейсике ты так и пишешь: PRINT A,B,C,D$ - получаешь значение переменных в остановленный момент.

Вот досада: хочешь посмотреть переменные в ЛЮБОЙ момент - и не можешь

далее, нашел ты переменную, 2 байта, а там D5 38. ЭТО СКОЛЬКО???

Кинуть в калькулятор или просто кликнуть кнопочку decimal так трудно?
Кстати, перед этим не мешает для начала определиться, нужно ли оно вообще в десятичном виде

[Vadim]

забавно это читать тов. Barmaley_m более чем в адеквате и про асм знает не по наслышке

Судя по его постам в других ветках я в курсе, но тут какие-то неуместные сравнения.

или наугад среди кучи данных (по т.н. eyecatcher), зная что вслед за чем лежит?

Если честно, то никогда глубоко не отлаживал своих программ. Всегда "отладку" делал в уме, смотря на текст программы. И уж если совсем затык (было пару раз) то уже пользуюсь отладчиком. А вообще переменные можно держать в одном месте. Да и для отладки конкретного участка не надо их смотреть десятками.

D5 38. ЭТО СКОЛЬКО???

Это 38D5, если переменная 16 бит. Мне совершенно не важно сколько это в десятичной системе.

нет здесь граблей.

Есть. Сам через такое прошёл. Умея программировать на basic очень трудно понять "как же работает комп". Если нет описания архитектуры от общего к частному и наоборот от простого к сложному. Когда нет описаний как работает скелет программы которая гоняет спрайты по экрану zx-spectrum. Как она отрабатывает логику. Не зная этого новичек пишет дикие проги на бейсике. Ужасающие по своей безграмотности. Многие, кстати, перейдя потом в маш.код, ассемблер, многое принесли из тех ужасов бейсика.

направления в программировании бывают разные и не стоит всех заставлять проходить свой путь.

Как раз я и предлагаю идти не моим путем, а более другим :-) более коротким и эффективным. А то что направления бывают разные я в курсе. Можно только 3D графикой заниматься и не знать про аппаратуру вообще ничего (мы говорим в разрезе ZX-Spectrum и подобных машин, а не современных монстров), но знать при этом как же "работает комп" всё же полезно. Сколько я видел программистов, учившихся в свое время на ПОВТ'е и которые совершенно не представляли, зачем нужен проц, что такое прерывания, как обменивается программа с внешним миром данными и прочее. При этом они писали базы данных простейшие, используя для сортировки метод "пузырька" и ни секунды не сомневались что они и есть программисты....
Ещё пример где-то прочитал не помню уже, что программистка одна сдавала программу на паскале, писала на роботрон 1715, в TP 3.0 некую базу данных, так вот, у неё при выводе результата были всполохи символов искореженных, она всё не могла от них отделаться а потом плюнула и всё списала на неисправность компа, а между тем причина была в том, что луч пробегал во время вывода символов. Он ж "реальный" программист, зачем ей знать такие тонкости....

нехватку регистров в асме уже никто не помнит? память короткая?

Вот представь - Нет! Никогда у меня не было случаев, что бы регистров не хватало, что капец. Нет, конечно бывает, что для красивой и быстрой реализации нужен ещё один 8-и или 16-и битный регистр. Приходится извращаться, но это очень редко бывает. По первости, когда я пришёл из бейсика это было нормой. Я вообще не понимал как можно при таком малом кол-ве регистров хоть что-то писать. Почему так думал? Да потому что работал шаблон мышления - регистры это почти переменные бейсика, только своеобразные. А это ведь не так! Вообще не так! И таких вот шаблонов (у меня по крайней мере была) куча. О этих граблях я и писал. Конечно, если человек всю жизнь будет писать алгоритмы на лиспе или прологе то все вышеописанное ему ни к чему. Но я то думал, что мы говорим о спектруме. О программировании под него. Или нет?

бейсик (и любой алгоритмический язык) тем и хорош, что ты заморачиваешься только с алгоритмом, но не с борьбой с машиной.

Да это понятно. Много раз уже это сказано.

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

Я как предлагал выше? Сначала изучаем двоичную и 16-и ричную системы. И не так что "аааа, да понятно всё" и забыли вопрос. Сколько я людей ловил на том, что реально они не понимают. Нужно кристальной чистоты понимание и уже потом двигаться дальше. Это как если мы толком не одели коньки то учиться кататься бесполезно.

---------- Post added at 15:00 ---------- Previous post was at 14:51 ----------

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

Это почти слово в слово говорил и я и другие люди мне, когда такой вопрос обсуждали ещё лет 10 назад. Так оно. Хоть все и не реально на асме написать, но побольше чем сейчас - вполне реально, а то сейчас даже драйверы для видях пишут на Си. И получаем кривоту кривейшую. Не раз уже встречал случаи когда производитель так и не избавлялся от фатальных ошибок, бросал продукт и начинал "новую версию".
Напоминаю, мы о спектруме говорим, а не о ПЦ.