Оберон-клуб «ВЄДАsoft»

Выделено из темы «Кросс-средства для программирования под МП 1801, 1806, 588».
Дорогой hobot!

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

Всё зависит от целей, от задачи, которую я ставлю. Т.е. мне нужна такая среда, которая будет одной кнопкой делать программу для Спектрума, а другой — для УК-НЦ, притом программа эта будет понятной для не-гика УК-НЦ. Например. В книгах по стилю программирования советуют избегать "магических цифр", т.е. угадай что делает?

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

Менее "магическим" был бы такой код:

Тут хотя бы понятно, что что-то читается откуда-то.

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

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

Так вот наша задача — уйти от "магии" в разработке. Спрятать тонкости и особенности платформы, выдвинув наружу только самые концептуально понятные сущности. Такого рода "магия" старых платформ никому не интересна, она из области вымирающих динозавров. "Магия" новых платформ интересует очень многих, но с течением времени тоже неизбежно архаизируется. Это и есть моя область интересов. Разработка таких концепций, позволяющих сгладить различия между платформами. Бонусом будет появление игры сразу на целом парке платформ. Впрочем, не только. Ещё бонусом будет появление среды, в которой можно будет писать программы, особо не заморачиваясь на какой платформе потом их можно будет запускать.

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

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

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

Мой интерес сдвинут от конкретных платформ в сторону "программирования вообще", без опоры на конкретную платформу, а вернее даже с опорой на разные платформы, но в едином стиле; и многие средства разработки уже предоставляют такие междуплатформенные возможности. Проблема только в том, что модерные средства разработки совершенно не экономят ресурсы компьютеров. Это обычно виртуальная машина или же интерпретатор, которые реализуются поверх платформы. А средства, позволяющие делать компактные программы на родном машинном коде сейчас идут на убыль, потому что в среде программистов бытует стойкая ассоциация "Си[натив] это опасно, а C#[управляемый код] — безопасно". Ассоциация правильная в отношении языка, но безусловно неверная в отношении подхода [натив]/[управляемый код]. К тому же здесь часто забывают о том, что, давая безопасность, такие средства забирают прозрачность, простоту и свободу выйти на уровень машинного кода да и вообще выбирать платформу, отличную от предлагаемой виртуальной машины.

У многих программеров большой пробел в образовании, я бы даже сказал, брешь в области тех средств, которые позволяют соединить безопасный управляемый код и натив, машинный высокоэффективный код. В сообществе программистов имеются самые поверхностные, а часто превратные знания о таких языках программирования как Modula-2, Modula-2 rev. 2010, Objective Modula-2, Modula-3, Ada, Oberon, Oberon-2, Oberon-07, Active Oberon, Component Pascal. А это целый пласт самобытных языков и диалектов, которые совершенно незаслуженно проигнорированы. Чтобы слегка восполнить этот пробел — существует данный форум.

Что касается УК-НЦ и PDP-11, то у меня к ним интерес более чем умеренный. Просто если получится, будет здорово. Но с вашей помощью. А что получится? Да вот та самая среда разработки на языке, которого "родного" для УК-НЦ просто нет. Притом очень даже прогрессивная. И не требующая от следующей генерации программистов особо вникать в "потроха" УК-НЦ и тонкости машинного кода PDP-11. Которая для MSX позволяет программить как на MSX-Basic (привычным образом), а для Спектрума — как на Спектрум-Basic. Такая среда сможет дать потенциал переносить игры с ретро-платформ, таких как БК, ДВК и УК-НЦ на Windows и Linux. Ну и ещё много других вкусностей.

И то, что ты называешь "ковырянием бублика снаружи" — не попытка втиснуться со своей программой (игрой) и языком, на котором она написана, в прокрустово ложе платформы УК-НЦ и её средств разработки, а нечто совершенно противоположное — попытка подтянуть платформу с её особенностями под конкретные язык программирования и стиль разработки (XDev). И в этом смысле УК-НЦ станет "галочкой" в записной книжке в списке поддержанных XDev платформ, а не переходом на старинную платформу, на которой теперь предстоит жить и работать, хотя бы и в качестве хобби.

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

>Так вот наша задача — уйти от "магии" в разработке.
>Спрятать тонкости и особенности платформы, выдвинув наружу только самые концептуально >понятные сущности.
Это я понял с самого начала, когда только сунулся читать что по теме.
Как раз под этим я подразумевал не логичность твоего подхода, что бы устранить магию,
надо её перехватывать и каким-то образом ретранслировать, что бы для программиста её не было,
но для устройства она была! А как же иначе это сделать не став МАГИСТРОМ ) Получается логично,
что создаётся некий задел для среды, в которой возможно кто-то будет работать в будущем, но не
её создатель, который просто вынужден знать ВСЁ что хочет поддержать в своей среде? По другому
просто не получиться.

Простой пример:
Даже с учётом "МАГИЧЕСКИХ" средств, на основе только системных вызовов, без прямого обращения
к железу - невозможно написать универсальную программу для PDPlike ЭВМ - это конечно спорно, но
это касается вот какой стороны вопроса, всегда надо чётко знать - а какой терминал будет у Юзверя?
И вариантов не 1 и не 2 ))) Толпа ))) Ну уж 3 варианта точно есть, причём различия ESC-последовательностей и отображения символов довольно значительны. Почти все альтернативные
прошивки для граф.карт того времени включают в себя "эмуляторы терминалов" - тех с какими эти "видео контроллеры" предполагалось использовать - чувствуешь попытку "избавления от магии"?

>Такого рода "магия" старых платформ никому не интересна,
Мне интересна, поскольку позволяет делать оптимальный код для любимой ретро машинки ! )
>она из области вымирающих динозавров.
Но без её знания каким образов осуществить поддержку в новой среде?
Забить на неё не получиться, проще, если нет времени, желания, поддерживать всё подряд,
отказаться от PDP в целом - ограничиться какой-то 1-й чёткой модификацией, но и её придётся
изучить по винтикам, что бы 100% совместимый код твоя среда переделывала из программ без "МАГИИ"
в "МАГИЧЕСКИЕ" ! )

>Поэтому опытный программист, решающий не проблемы заплаток конкретной среды, но >занимающийся более фундаментальными вещами, делает ставку на язык и интерфейсы библиотек.
Мне нравиться как хобби использование на ЭВМ класса ДВК связки из OMSI PASCAL + MACRO-11.
Это очень привлекательное хобби или просто я "зануда такой" )

>Мой интерес сдвинут от конкретных платформ в сторону "программирования вообще",
Я понимаю - это в целом наверное интересно и прогрессивно и заставляет тебя так или иначе
ваять самому или использовать что то кросс платформенное, но как ты сам пишешь ниже - когда дело
снова доходит до уровня платформ - всегда (!ВСЕГДА!) встаёт вопрос : экономии ресурсов,
оптимальности, то есть требуется та самая МАГИЯ конкретной платформы на выходе т.или иначе.

>а C#[управляемый код] — безопасно".
Вот ты же сам восстаешь, когда тебе дают "чёрные ящики" в любом виде :
> такие средства забирают прозрачность, простоту и свободу выйти на уровень машинного кода да и
> вообще выбирать платформу, отличную от предлагаемой виртуальной машины.
Может это и есть (на уровне подсознание) стремление оставить за собой право "МАГИЧЕСКОГО" подхода.

Теперь кратко резюмирую всю эту лирику, что я тут написал:
1. Ты подразумеваешь среду в которой программист пишет программу не для конкретной машины с
её там тех. параметрами, терминалом,а для некоторой виртуальной машинки? или несколько другой
подход, когда ты крутишь исполняемый на вирт. машинке загружая её предварительно в память
реального компа (ОС) и перехватывая и подминая по себя все ресурсы (ну ты хакер ! Ледовые пираты перегляди = там роботы классные!). Просто по моему это довольно сильно два разных подхода.

2. Пока я не вижу ПКМ в рамках разработки того, что ты назвал XDev/Pdp11Dev
рентабельности ? Зачем? PDP-11 узкая среда машин, ниша заполненная увлечёнными
людьми, профессионалы. Повторю для увесистости "Увлечённые профи!", люди от науки
разных направлений, радиолюбители и просто люди с хобби в виде УК-НЦ вроде меня.
Нам нравиться наш магический лес, наша магия.

(Так! Стоп, краткое Резюме становится больше "некраткой лирики").
Есть пожелание продолжить обсуждение и обмен мнениями в целом,
на страницах этой темы или в этой разделе и есть ещё просьба,
ознакомься подалуйста вот с этой статьей
https://geektimes.ru/post/261074/ - Никиты Зимина, а конкретней с
её разделом "СИНТЕЗ".

Я на связи, само собой.
С уважением,
[hobot]

_________________

Ищу игру "СТРАНА МОНСТРОВ" [monstr.sav] для ДВК.

Спасибо, hobot, за ссылку, интересная статья, хоть и коротковатая.

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

Но у меня есть опыт простой унификации, например, такой как в игре Dark Woods, собираемой для ZX Spectrum, Windows, Linux и Java ME. Но это чёртова неблагодарная работа по изучению тонкостей всех этих платформ. И только маленькая вероятность, что результатами её (в виде наработок и библиотек) захочет (и сможет) воспользоваться кто-то ещё. Так что ты прав, но вот Dark Woods, хоть и не вполне закончен, но есть. Его основной код в принципе переносим и на БК или УКНЦ, но низкоуровневые процедуры всё равно должен писать магистр. Чудес не бывает.

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

Получается, никак. Нужно искать спецов. Даже сравнительно большое количество спецов по ретро чрезвычайно трудно замотивировать на что-либо сложнее ответов на вопросы (пример тому — форумы по Спектруму).

Ну, инкапсуляция (спрятать сложное в чёрный ящик, выглядящий просто) — один из базовых принципов объектно-ориентированного программирования. Как я могу быть против.

Ну тогда расскажи нам, как же обойтись, в конце концов, без магии вообще? Я вижу только один способ — упрятывание магии.

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

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

Да ради Бога, уважаемый! Любите свою магию, кто ж запретит-то. Я в магии PDP-11 не волоку, просто искал единомышленников-магистров, которым бы было интересно разработать такую подсистему. Но раз неинтересно, что ж поделать-то.

В целом, поддержку Олега.
Обычно (неправильно) сначала создаётся железо, а затем -- средства программирования. Вирт более чем убедительно показал: магия -- это следствие "сочинительству", а не конструирования. В самом деле, когда рассчитывается схема электропитания -- сначала смотреть на источник питания (высокий уровень абстракции), и только потом решают какие будут детали. В хирургии, прежде чем перейти к уровню "вырезать нахрен" -- сначала оценивается общее состояние пациента и проч. В программировании, вроде как, дошли до понятия "архитектура". Собственно, кодирование (при правильно поставленном процессе) занимает не более 20% времени от общего времени цикла разработки.
Что касается наследуемой магии, объективно -- магия зло. И нужно стараться избегать её всеми доступными средствами. Если магия заложена в железо изначально -- уже ничего тут не сделаешь. Зыбкое болото под ногами будет всегда. Но абстракциями можно проложить тропинки между ямами трясины. И это более верный ход, чем всё-таки полагаться на магию. Из говна и палок Кремля не построить))

_________________
Действия профессионала предсказуемы. Но в мире полно любителей!