101 Basic Computer Games

Недавно я натолкнулся в сети на книгу, о которой никогда не слышал.
Книга называется "101 Basic Computer Games". Она была выпущена DEC в 1975 году
и содержит тексты игр с аннотациями. Игры написаны на BASIC, на компьютере PDP-11.

Очень интересная коллекция для начинающих программистов, и не только.

Коллекция игр с описаниями и переводом на другие языки программирования находится по адресу:

https://github.com/coding-horr... uter-games

4

Сообщение от Quiet Snow Т.е. впоследствии люди писали нормально там без GOTO.

Не знаю, не видел современный код. Говорю по книжке: "Численные методы и программирование на ФОРТРАНе. от 1969 года. Могу скинуть, у меня есть. И вот там много такого типа:
if(a(b) - c(d)) 13, 14, 15

Сообщение от Quiet Snow Макаронинг - это "простое решение"?

Добавлено через 3 минуты

Сообщение от Quiet Snow Макаронинг - это "простое решение"?

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

Добавлено через 42 минуты

Сообщение от locm Если не поняли, происходит одновременно возврат и очистка стека.

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

1

Сообщение от CoderHuligan Ну а если нам нужно ошибку обработать? К примеру прыгнуть на два кадра стека вверх? Выйти в главную функцию или код?

Компилятор уже написали?
Приказывайте какой код он нагенерил, иначе это обсуждение не имеет смысла.
Вам нужно пообщаться с Hretgir.
У него тоже идеи по поводу неидеальности процев и необходимости изобрести квадратное колесо правильный процессор. https://www.cyberforum.ru/blog... g8346.html

Осуществление установки флага Zero
Если равенство проверяется через вычитание, то почему не аппаратно?

0

Сообщение от locm Вам нужно пообщаться с Hretgir.

Да читаю я его блог, только ничего не понимаю.

Сообщение от locm Компилятор уже написали?

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

0

Сообщение от CoderHuligan от 1969 года.

Забудь про это старьё. До конца 80-х вообще никакой массовой культуры программирования
не существовало. Никто и близко не понимал как программировать. Оно в зачатке было.
Первые быстрые процессоры, которые позволили делать 3D в реальном времени сильно раскачали
всю индустрию, вот тогда всё это попёрло, демщики, 3D шутеры. Если математики были условно
всегда, то программисты "рожались" именно тогда. Уровень рос экспоненциально, но не у всех))).
Потому что именно тогда появился нормальный интернет, все начали делиться опытом, что дало
сильный пинок в развитии кодинга. И к стилю кода требования именно тогда сформировались.

Сообщение от CoderHuligan Написать-то можно достаточно быстро.

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

Сообщение от CoderHuligan Когда существует спецификация на функцию где черным по белому прописаны все необходимые состояния, то о каком макароннинге можно говорить?

Спецификация существует и там и там, а мы про код, и не ты ли тут писал про рекурсию,
а это очень близко. Объясняю то что не запрещено - разрешено и будут особо одарённые кони-люди
использующие одни состояния как части других(и именно через GOTO). И никакая схематика тебе
понять это говно не поможет на приближении дальше 2-3 шагов, у рекурсии та же беда,
написать просто - обслуживать невозможно. И линейно вычленить процесс и оттрассировать
ты не сможешь т.к. он созависим. Расчёты и проверку делает автор кода и если он где-то
лоханётся - то кабзда. Обе эти вещи устойчивы к крайней трудности и невозможности доработки.
Это и есть истинный макаронинг во плоти. Полный запрет GOTO лишает читающих код
такого дерьма. А оставили GOTO потому что при разработке он бывает нужен единично
и то разумеется если код поддаётся реструктуризации - лучше это сделать.
Убирая одно говно и вваливая заместо него другое - ты не делаешь лучше, решение простое и
очевидное, не использовать GOTO когда оно не требуется(ВУ сугубо логика кода), и использовать только
если это объективно принесёт пользу(например если требуется реструктуризовать кусок в 300-1000 строк
а можно обойтись одним GOTO).

Сообщение от locm У него тоже идеи по поводу неидеальности процев и необходимости изобрести квадратное колесо правильный процессор.

Какие бы мотивы у чувака не были, но неидеальность такой шляпы как Эльбрус очевидна.
Я когда открыл документацию - просто вспух. Туда с гарантией мало кто в асм полезет,
это рак мозга. А так оно по сути пожизненно обречено на "плас плас", "линух" и иже с ним.
Почему раньше люди делали всё обдуманно и выделяли фундаментально очевидные вещи,
те же intel начали за здравие всё было круто, обратная совместимость, приросты скорости.
Но самое главное - простой и понятный ассемблер, универсальный инструмент для создания средств
разработки, ОС и оптимизации x86.
Теперь же только приросты ядер и скорости SIMD, а не скорости базовых x86-x64. Т.е. маркетинговое
вонючее враньё. Но параллелится то не всё и это прекрасно людям известно. И ВУ не везде
хорош это тоже известно. В миру пока острой потребности нет, все смирились с тем что хороший уровень
железа достижим только Intel-ом да AMD, а в нашей стране имхо актуально, ну потому что сколько
можно "сосать" у зарубежки. Почему столько наших мозгов топовых(кто при возможностях) нихера
не могут сделать, а в своё время наши и к PowerPC руку приложили. Создали бы клон интелов
по инструкциям уровня 486\P1, а по мегагерцам современный и дальше с этого места уже бы гребли
без излишнего маркетинга и лжи. С видеокартами та же херня. В общем не хотят наши пройти тот же путь
но правильно... Идут через жопу.

0

Сообщение от Quiet Snow Но параллелится то не всё и это прекрасно людям известно.

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

Сообщение от Quiet Snow что хороший уровень железа достижим только Intel-ом да AMD

Яблочники перешли на ARM и говорят что производительность выше.

0

Сообщение от locm Яблочники перешли на ARM и говорят что производительность выше.

Яблочники это особый вид людей, там такой уровень поклонения бренду что это уже новая мировая религия.
Помню был весёлый ролик про 4-й айфон. Как-то так эти люди живут:

https://www.youtube.com/watch?v=EqWIOrCDqbQ

А что такое ARM мы знаем по мобилам, байкал наш вон тоже пытались, но там обсёр конечно был
сильно очевиден, и никакой аппаратно ускоренный и критически заточенный софт это понимание не изменит.

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

Архитектурно же увеличивают IPC. Да и по железу бы копали, искали новые варианты и подходы, а не
обманывать людей как это сейчас происходит с этими дебильными бустами, которых нет. Уже вообще
не понять, что будет работать быстрее, а что наоборот. А так по сути хоть 50 ядер, если алгоритм
не параллелится - то не будет быстрее и всё упрётся в 1 поток, так и снижается производительность
многопоточных прог где всё схлопывается в 1 поток и образуется ботлнек.
Мы то понимаем что вот сейчас эти цифры которые нам дают по приросту к IPC - это ложь, т.е. каждый раз
по 15-20%, оно могло быть так на первых порах, когда не было решения на дальнейшее увеличение частот,
но не сейчас. Я это пишу чтобы у людей сложилась устойчивая картина, что там всё упёрлось 100 лет назад
и догнать на самом деле можно пока западные маркетологи извиваются как сосиски на сковородке, можно
напереть на здравый смысл повторить успех того, что было в начале и середине 90-х и спокойно пойти дальше.
Для людей это сделать, для наших и возможно не только. Потому что амеры делали для людей, говно попросту
иначе не стало бы так популярно в остальном мире.

Когда нужна точность и логика то не канает подход "мы не такие как все", в т.ч. эта клоунада с андроидами,
которые высосали из пальца свой адский шлак, а кони-люди это позорище склевали ради социалок и селфи.
Такие вещи как UI не могут быть настолько субъективны, насколько нам пытаются это подать.
Примерно эти тенденции высмеивали 10 лет назад с актёрами из "назад в будущее":
https://youtu.be/L2xvITU7gdI?t=159
Там кстати про Трампа интересно сказано. Ну и в целом прикольно обыграли "деградацию".

0

Сообщение от CoderHuligan Не должна позволять работать рекурсивно. Это обеспечивает в разы большую безопасность кода.

Ну удачи вам в разработке и отладке алгоритма нерекурсивного обхода двоичного дерева.

0

Сообщение от Замабувараев Ну удачи вам в разработке и отладке алгоритма нерекурсивного обхода двоичного дерева.

Такие алгоритмы давно существуют. Разработаны и отлажены.
Я ж не против рекурсии. вы просто невнимательно читаете. Я против рекурсии в процедурах, но не против рекурсии в функциях. И я хочу четко разделить понятие процедура от функции.

Сообщение от Quiet Snow Полный запрет GOTO лишает читающих код такого дерьма.

Переходы - основа любого алгоритма. Код:
имеет по крайней мере три интересные особенности:
1. полное отсутствие ключевых слов типа while, continue, break. Это упрощает сам язык.
2. каждый блок кода имеет уникальное имя. Напомню, что в структурном коде блоки безымянны.
3. А это позволяет легко документировать такой код. то есть создавать описание шагов алгоритма ссылаясь на имена блоков кода. При этом понимание алгоритма происходит уже на стадии чтения српецификации.
4. Легко верифицировать и документировать код автоматическими средствами, так как у нас есть адреса блоков кода.
5. ЛЕГКО СОЗДАВАТЬ АЛГОРИТМЫ ДАЖЕ ОЧЕНЬ СЛОЖНЫЕ БЕЗ ПОТЕРИ ЭФФЕКТИВНОСТИ. В структурной парадигме только за счет потери эффективности.
Метки не обязаны быть чисто цифровыми. Мы получили еще одну абстракцию по типу функции: именованный блок кода. Недостаток номеров строк очевиден: придется как-то синхронизировать документирование и написание кода, так как номера строк могут измениться при пересчетах командой renum. Это конечно пережиток.

0

Сообщение от CoderHuligan каждый блок кода

Он же одноразовый. Повторно использовать нельзя, иначе будет конфликт переменных и меток внутри «блока» с моими.
Нельзя скомпилировать и использовать как готовую библиотеку.
Даже в отдельном файле такой «блок» нельзя использовать. Как их вызывать? У нас будет программа из одного файла? Хелловорды только писать? Смех.

Сообщение от CoderHuligan ЛЕГКО СОЗДАВАТЬ АЛГОРИТМЫ ДАЖЕ ОЧЕНЬ СЛОЖНЫЕ БЕЗ ПОТЕРИ ЭФФЕКТИВНОСТИ

Наоборот. Метки, номера строк и прыжки делают оптимизацию невозможной: никаких встраиваний, раскрутки циклов, распространения констант, уничтожения переменных, удаления мёртвых кусков кода, параллельных вычислений, мультискалярных операций. И на выходе спагетти‐код работает медленнее, чем код на функциях.

Сообщение от CoderHuligan Мы получили еще одну абстракцию по типу функции

Что за функциофобия. Как бы так сделать, чтобы было как в функциях, но без функций.

0

Сообщение от Замабувараев Повторно использовать нельзя

На блок можно переходить из разных мест кода.

Сообщение от Замабувараев Нельзя скомпилировать и использовать как готовую библиотеку.

Для этого есть файлы и функции. Смысл блоков совсем в ином.

Сообщение от Замабувараев Даже в отдельном файле такой «блок» нельзя использовать. Как их вызывать?

Их не вызывают: на них переходят.

Сообщение от Замабувараев Метки, номера строк и прыжки делают оптимизацию невозможной: никаких встраиваний, раскрутки циклов, распространения констант, уничтожения переменных, удаления мёртвых кусков кода, параллельных вычислений, мультискалярных операций. И на выходе спагетти‐код работает медленнее, чем код на функциях.

Почему же? Если блок будет оформлен например по типу Си: {блок} и будет иметь уникальное имя: имя{}, то можно использовать и внутренние переменные и всё остальное.

Сообщение от Замабувараев Что за функциофобия.

Функция должна быть функцией. А процедура для ускорения кода и упрощения реализации.

1

Сообщение от CoderHuligan полное отсутствие ключевых слов типа while, continue, break. Это упрощает сам язык.

И ухудшает читаемость.

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

Понадобилось доработать код и доставить несколько десятков строк между 20 и 30 и номеров не хватило. Предлагаете править весь код и изменять номера?
Короче не нужно пропагандировать старые методы. От них не зря отказались.

Сообщение от CoderHuligan А это позволяет легко документировать такой код. то есть создавать описание шагов алгоритма ссылаясь на имена блоков кода.

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

Сообщение от CoderHuligan Метки не обязаны быть чисто цифровыми.

Но в вашем примере они числовые.

Сообщение от CoderHuligan Это конечно пережиток.

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

0

Сообщение от locm И ухудшает читаемость.

А зачем читать код? Это миф что код должен сам себя документировать. В реальности ничего такого нет. Вместо всех этих while и т.п. можно на чистом английском/русском/грузинском написать что делает код, описать шаги алгоритма. Если нужно действительно выловить какой-либо баг - обращаемся к коду. Так мы уже будем четко представлять что он из себя представляет. Короче вы меня не переубедите, что код надо читать, как читают романы. Ничего там интересного нет. всё интересное в коде это его комментарии, и если их нет читать такой код это значить погрязть в болоте,и надолго.

1

Сообщение от CoderHuligan Если блок будет оформлен например по типу Си: {блок} и будет иметь уникальное имя: имя{}

Невозможно. Как вы определите конец блока?
В си конец блока обозначается фигуристой скобочкой.
А номер строки и метки никаких фигуристых скобочек не имеют. Новая метка — это конец предыдущего блока или ещё один вложенный друг в друга?

Каким образом у вас будут работать переменные объявленные выше прыжка?

0

Сообщение от Замабувараев Как вы определите конец блока?

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

Сообщение от Замабувараев Каким образом у вас будут работать переменные объявленные выше прыжка? Код

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

0

Сообщение от CoderHuligan По закрывающей скобке

В бесике принят verbose синтаксис, а всякие закорючки, псевдографику, ASCII-арт вместо синтаксиса и визуальный мусор из точек с запятой оставьте в си.

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

Вот минималистичный пример, который показывает «блоки кода» — это пересекающееся множество:

Сообщение от CoderHuligan никаких проблем подобного плана быть просто не может

Просто пример, который показывает проблему: переменная j оказывается не инициализирована
Добавлено через 15 минут

Сообщение от CoderHuligan Объявления переменных читаются на этапе компиляции

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

1

Сообщение от CoderHuligan Это миф что код должен сам себя документировать.

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

Сообщение от Замабувараев То есть какая‐то переменная, которая нужна только внутри блока и которую после блока можно уничтожить, будет существовать всё время жизни программы?

Всё на самом деле зависит от объёмов данных, частоты инициализации и накладных расходов на неё.

Добавлено через 11 минут

Сообщение от CoderHuligan Я против рекурсии в процедурах, но не против рекурсии в функциях.

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

0

Сообщение от Quiet Snow Нужно ещё поискать такого дятла, который будет "рекурсировать" в процедуре.

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

Вложения

Fern.zip (6.2 Кб, 8 просмотров)

0

Сообщение от Mikle Quits Рекурсия - одно из лучших изобретений в программировании.

Одно из худших по читаемости и понятности. 99% это бесполезные фракталы. остальной 1% это механизмы,
не поддающиеся контролируемой трассировке мозгами дальше нескольких итераций, потому что они,
повторюсь, созависимы.
Фракталами не занимаюсь но вот старый адаптированный на бейсик исходник из книги если уж надо.
https://www.cyberforum.ru/post1480863.html без процедур.
Судя по "папаротнику" идея также не твоя, так что не понимаю к чему это всё.
Рекурсией ради рекурсии не занимаюсь, поиск по файловому дереву разворачивал в линейный вид,
проблем не увидел, и не выпендрёжа ради. Как и любую рекурсию для себя разворачиваю ВСЕГДА
в линейный итерационный вид, т.к. уровень контроля на любом шаге - выше.

0

Сообщение от Замабувараев Вот минималистичный пример, который показывает «блоки кода» — это пересекающееся множество:

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

Сообщение от Замабувараев Просто пример, который показывает проблему:

Вы тут просто смешали коней и людей. Структурный код с неструктурным. Сами создали проблему, чтобы показать: ой как все плохо)).

Сообщение от Замабувараев Но создаются на этапе выполнения

В каких то языках - да. Например в Паскале - нет.

Сообщение от Замабувараев То есть какая‐то переменная, которая нужна только внутри блока и которую после блока можно уничтожить, будет существовать всё время жизни программы? Тогда получаете использование памяти вхолостую.

Потенциально памяти уходит одинаковое количество. Вы же её прописали в коде. Компилятор может оптимизировать если она нигде не используется. Но это ваш косяк.

Сообщение от Quiet Snow Но тебе пишут про другое, про то что влияет на скорость считывания кода глазами и мозгом, а это прямо влияет на скорость разработки, т.к. разработка это не 1 день.

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

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

0

Сообщение от Quiet Snow вот старый адаптированный на бейсик исходник из книги если уж надо

Там написано:

В божеский вид посредством манипуляций с палитрой привести не удалось, может кому из форумчан удастся.

У меня достаточно "божеский" вид?

Сообщение от Quiet Snow Судя по "папаротнику" идея также не твоя, так что не понимаю к чему это всё.

Речь не о понтах своими идеями, а о примерах рекурсии. Я взял когда-то именно идею, а не код, и переписал с нуля. И у меня большая часть кода - это украшательство (процедура DrawLine, её можно заменить на обычный Line, потеряв раскраску), а само формирование фрактала вот:
Что такое фрактал папоротника, если описать его человеческим языком:
1. Получаем на входе координаты начала и вектор направления линии. Если вектор слишком короткий - ничего не рисуем (выход), а иначе...
2. Рисуем эту линию.
3. От конца нарисованной линии тем же методом рисуем следующую (продолжение ветки) немного короче и чуть-чуть повернув угол.
4. Так же от конца рисуем две линии, сильно повернув углы вправо и влево и значительно короче (начала боковых веток)

А теперь глянь на код, ведь это как раз то, что я описал человеческим языком. Логика в чистом виде.

0