Ты сам когда-нибудь или кто-то из твоих знакомых натыкался на этот баг? Я - никогда, хотя на бейсике на Спеке в свое время сделал немало. Сравнивать дробные числа на равенство - это плохая практика, от которой нас преподы предостерегали на самых первых лекциях. Так что данный аргумент не может считаться достаточным для отвержения бейсика в качестве инструмента программирования, в том числе игр.Сообщение от Lethargeek
Вагон и маленькая тележка. Часть из них упоминалась и на этой ветке. Диктатор, президент, хлебное королевство, Титан (Ground force zero). Когда-то я сделал на бейсике сапера - тоже можно было вполне сносно играть по настроению. Даже друзья в гостях играли. Сапер - это вообще заразная игра, на которую можно часы убивать, и она не требует ни скорости, ни еще чего-то особенного, чего нет в бейсике. Увлекает похлеще многих технично реализованных, но глупых игр на ассемблере. Одного моего знакомого даже исключили за это из института - он прогуливал пары и бегал играть в компьютерный класс - в сапера и "королевство".
"Взбесившиеся роботы" тоже хорошо и динамично получилось конвертировать, жаль только распространения им дать не получилось. Но может кто-то еще их делал на Спектруме, кроме меня.
Так что время все-таки подтвердило пригодность бейсика.
И что, сидеть и вручную скрупулезно проверять? Ты-то сам часто так делаешь?
Это зависит от размера программы. Если она хотя бы такого размера, как типичная программа вывода сообщения на экран, то глюк компиляции может далеко не сразу дать себя обнаружить. Хотя бы потому, что такого обычно не ждешь; обычно считаешь, что если глюк - то это в твоей программе, а не в ассемблере.
Что, предлагаешь писать программы на ассемблере без использования косвенной адресации, чтобы не глючили?
Прекрасно. Как насчет вывода на экран символа? Я уже не говорю про сообщение. Можешь написать такую программу без косвенной адресации, которая может вывести произвольный символ в произвольную позицию на экране?
Ты это еще не доказал. Вот как будет вывод символа на приведенных выше условиях - тогда поговорим.
Проблема в том, что прежде, чем делать вторые шаги, надо сделать первые, а без макросредств (поскольку они еще не изучены) это становится затруднительным.
Что еще за встроенный монитор, это о каком компьютере идет речь?Контрпример - Lethargeek, человек чудовищно ленивый, вялый, сонный и слабовольный
Провозился пару часов (потому что набирал машинный код ручками во встроенном мониторе)
Адреса в дисплейном файле обнаружил методом тыка (мануалов не было)
И потом, ты что, никогда ничего не программировал на бейсике (или других языках высокого уровня) прежде, чем взяться за ассемблер? Что, даже простейшей программы не написал? Из принципа что ли?
Ты так полностью и не рассказал свою историю овладения программированием - давай тогда полностью ее проанализируем, что и когда начиналось. Если уж твой пример детально рассматривать.
И что, считаешь, что и с коровой сработает? Ну давай, попробуй
Это не косвенная адресация. Это, по аналогии с ассемблером, прямая адресация. Типа LD A,(varX), LD A,(varY). Независимо от значений переменных в данном примере невозможна порча информации в других переменных или в тексте самой программы.
Косвенная адресация - это LD (HL),A. В зависимости от значения HL возможна порча чего угодно. В бейсике полных аналогов нет, есть приблизительный LET m(i)=a, но в случае неправильного значения i возможна порча только содержимого массива m, а остальные переменные или текст программы не будут затронуты.
В самом деле, так переводится красивее. Хотя не во всех контекстах применимо. Например, нельзя сказать: "Я вставил в программу проверки при выполнении", поскольку смысл искажается, будто бы я вставил в программу эти проверки во время того, как программа выполнялась.
А словосочетание "проверки времени выполнения" с чьей-то нелегкой руки стало общеупотребительным термином. Даже гугл-переводчик с русского на английский правильно перевел, там явно в базе было забито данное словосочетание.
В отладчике эмулятора видно только циферки, компьютер работает в нем несамостоятельно. Куда приятнее, когда компьютер, без "костылей" в виде отладчика, исполняет твою программу полностью самостоятельно, при этом осуществляя какое-то взаимодействие с внешним миром, а не просто числа в памяти складывая.
Когда есть только ассемблер - то компьютер ведет себя даже бесполезнее, чем калькулятор. Там хотя бы умножать можно и синусы вычислять, предварительно не изучая, что такое полиномы Чебышева.
Это ты не придуривайся. Мы вроде рассматривали программу, состоящую из одного сложения, а не цикла, забыл? И потом, чтобы сложение стало в цикле, надо сначала изучить, что такое цикл! Ты что, забыл, что когда-то этого не знал?
У тех, кто "напейсать" - не знаю.
А у тех, кто первый раз хочет написать игру и делает первые шаги в программировании - цель стоит написать хоть какую-нибудь игру, чтобы стало понятно, что это ему под силу. Ну и заодно освоить некоторые концепции программирования. Эти первоначальные цели в рамках бейсика достигаются.
Сразу никто не потянет проект, претендующий на название "лучшей игры года". Все равно придется начинать с чего-нибудь попроще и неприметнее, что скорее всего не получит широкого распространения и будет заброшено. Хоть на бейсике, хоть на ассемблере. Ты-то сам много своих ассемблерных программ 15-летней давности используешь по сравнению с тем, сколько их было тобой написано в те времена? И сколько в этих программах осталось кода 15-летней давности?
Это необходимые издержки производства. Программы выбрасываются даже в соответствии с хорошо проработанными планами. Например, Arun Kishan из микрософт в одной своей лекции рассказывает, как разработчики ядра винды, чтобы внести в него существенные изменения и не напороть глюков, приняли поэтапный план внесения этих изменений, что подразумевало разработку большого количества вспомогательного кода, который весь в конце концов был выброшен. И был достигнут успех.
Это твои аргументы?
Полезно изучать и знать вообще все, только это неконструктивный совет, он не дает руководства человеку о том, как в реальных условиях можно все это осуществить и не разочароваться раньше, чем будет достигнут результат.
Обоснуй, почему бесполезно. В играх что, арифметические выражения не встречаются? И косинусы тоже?
В том числе и личный опыт. Некоторые мои проекты застряли на ранних стадиях разработки, т.е. на вылизывании мелочей. Если бы эти мелочи были уже реализованы кем-то другим или входили в базовый набор средств разработки (как операторы бейсика) - то возможно, эти проекты и увидели бы свет.
Тролль.
У меня нет слов.
С помощью одной короткой строчки CALL PRINT на ассемблере невозможно напечатать сообщение или тем более значение выражения.
Какого еще чувства достаточности, зачем его вырабатывать?
Почему время зря потратил? Какие именно сформированы вредные привычки? Откуда уверенность, что эти же привычки не сформируются при работе с ассемблером?
Начинать обучение программированию с написания сразу длинных программ, минуя короткие? Ты часом не болен?
Не зря потратил, потому что он научился основам программирования и при этом получил результаты, которыми может гордиться - собственные работающие программы, которые делают не тривиальные вещи, вроде вывода на экран символа, а что-нибудь поинтереснее.
Ответить с цитированием