Ассемблер ничем не лучше бейсика с этой точки зрения. А даже и хуже. В бейсике есть хотя бы именованные переменные, массивы, строки, циклы наконец. Они придают программе и данным хоть какую-то структуру.
Я не против ассемблера, просто возражаю против того, что на нем легче программировать, чем на бейсике.
---------- Post added at 03:14 ---------- Previous post was at 02:42 ----------
Я вообще-то имел в виду не кросс-компиляцию, а работу с ассемблером в эмулируемой системе (или на реале). Но даже если писать программу с прицелом на эмулятор: видишь, ты сам описал, сколько всего нужно. Какие-то bat-файлы создавать, стыковать ассемблер с эмулятором. С бейсиком проще. Там всё сразу есть. Не надо изучать доки к куче других программ. И программа на бейсике (если только она не делает какие-нибудь POKE или USR) не может привести к сбою компьютера.
И опять-таки: допустим, произошел сбой при пробном выполнении программы на ассемблере. Как в этом случае можно проследить его причину, если память перепахана? Бейсик же обычно останавливается с ошибкой, потому что там проверки постоянные на выход за пределы диапазона, NEXT без FOR и так далее.
Это все ничто по сравнению с преимуществами, которые предоставляют интерпретируемые языки типа бейсика. При останове программы в них можно распечатать любые данные, можно выполнять сложные команды этого языка или куски отлаживаемой программы, вычислять выражения. Изменить текст программы и продолжить ее работу. Всего этого в отладчиках компилируемых языков нет, даже отладчик Visual C++ сильно ограничен в своих возможностях к копанию в программе, что уж говорить об отладчике Unreal.
Видишь ли, я имел в виду такие ошибки, которые не сами по себе приводят к сбою, а портят где-нибудь содержимое памяти, так что программа сбивается спустя долгое время в другом месте. При программировании на бейсике вероятность подобных ошибок уменьшается, так как во-первых, имеются именованные переменные, и при присвоении переменной A нельзя испортить переменную B. Во-вторых в бейсике постоянно происходят проверки на предмет выхода за пределы диапазона и другие ошибки времени выполнения. Просто посчитай, сколько всего разных ошибок диагностируется бейсиком (сообщения 1-9, A-R). По сравнению с этим, сколько ошибок диагностируется ассемблером? Только две! Программа либо правильно работает, либо слегка глючит, либо компьютер полностью сбивается. А на бейсике больше вероятность останова программы с диагностикой на ранних стадиях ее выхода из-под контроля.
Это смотря какую игру. Начинающий программист, думаю, не потянет работу класса Sea Dragon, например. Такой программист должен понимать ограниченность своих возможностей и начать с чего-нибудь попроще, вроде тех примеров, что ранее приводились в этой ветке. Простую же игру не только можно, но и нужно писать на бейсике. Это быстрее приводит к успеху.
Маленькие успехи способствуют поддержке энтузиазма и стремлению к большим успехам. Рано или поздно человек сам осознает ограниченность бейсика и потянется к чему-нибудь более серьезному. Ведь почти все из нас этот путь прошли, так зачем от него отваживать новичков?






Ответить с цитированием