Скрестить ZX и ПЦ

[Oleg N. Cher]

dosikus, а вообще интересная позиция "ты меня привлекай, а я буду отбиваться ногами, и ни за что ты меня не привлекёшь". Для мазохистов от IT - самото.

Я мог бы попробовать аргументированно поговорить с опытным и зрелым программистом (именно с программистом, а не с кодером; кодер - не всегда программист) о достоинствах Оберона. Они лежат в другой плоскости, чем сишные. Сишные достоинства - есть теперь и идут на убыль. Кто думает о том, что придёт на смену Си, кто мыслит категориями будущего - тот вряд ли будет доволен если Си повально заменят Java/C#. Несмотря на их достоинства.

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

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

Ну так что? На чём будут программировать? Вероятно, платформы будут мощными. Вероятно, будет совместимость с Java/C#. Может даже с С/С++/Objective C - просто дань горам готового кода. Что делаю я. Задел на будущее. Мне не нравятся все эти языки. Но работать и стыковатся с кодом, написанным на них, как-то нужно. Поэтому я беру Оберон, который я могу транслировать в Java и Си. Соединяю с кодом на Java и Си, который рассматриваю как временную меру пока не будут готовы библиотеки на Обероне. Можно сделать предположение, что через 50 лет будет поддержка энцатой версии SDL и SQLite. Я беру и делаю биндинги. Мой путь - это путь безболезненного выхода из не нравящихся мне языков и технологий, вместо этого - ставка на простой и логичный язык, здравую нотацию, в чём-то неустоявшуюся, но это не всегда и недостаток, есть где порезвиться. Если бы вы начинали не на ZX-бейсике, а на Обероне, то сейчас бы плевались на Си и Java вместе со мной, а то и лучше меня.

---------- Post added at 10:33 ---------- Previous post was at 10:29 ----------

Мне оно без надобности , имею ZM-VE200 ...

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

[denpopov]

Можно сделать предположение, что через 50 лет будет поддержка энцатой версии SDL и SQLite.

бугога, предполагай ищо

[Alex Rider]

Очень много людей варится в этом, вот и много работы сделано.

Есть и стандарты, есть и рекомендации, но они, пожалуй, слабоваты.

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

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

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

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

Олег, ну мы же понимаем, что твое сообщение "Память не может быть 'read'" к языкам отношения не имеет - это аппаратное прерывание на платформе x86, которое ОСью транслировано в исключение, которое не обработал код (ибо нежданный Access Violation обрабатывать бессмысленно)? Все эти средства отлова ошибок хороши когда ты дебажишь свой код, пользователю они не дадут ничего. Олсо при отладке кода в современных нативных IDE тебе тоже про все это расскажут. Мало того, эта инфа есть и в отправляемом дампе, только пользователю с нее ни жарко, ни холодно.

Не поверишь, но иногда простая алгоритмическая перекомпоновка даёт больший выигрыш, чем продвинутая машинная оптимизация,

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

[Oleg N. Cher]

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

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

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

Ещё какой атрибут. Если C# только под одну платформу, то хоть казачка танцуй, а так оно и есть. И ничего ты тут не изменишь. Правда, тебя будут ещё долго водить за нос словом "кроссплатформенность", делая эмуляторы одной платформы - дотнета - разной мощности для разных платформ.

Схема "натив" = "опасная работа с памятью" неверна, просто типична. Указатели на динамические типы в Обероне могут указывать только на эти типы. Есть строгая охрана типов. Обязательная проверка индексов массивов (что в XDev я, впрочем, обхожу системным конфигуратором проекта). Утечки могут иметь место при неосвобождении ресурсов, но работа с памятью автоматизирована, со сборкой мусора. Несмотря на натив. Ухвачены самые важные тенденции безопасности, к которым ты, возможно, привык в шарпе и жаве, но без потери натива.

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

Олег, ну мы же понимаем, что твое сообщение "Память не может быть 'read'" к языкам отношения не имеет

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

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

Чем больше и тяжелее поезд - тем тяжелее ему и поехать, и остановиться. В случае языка так оно и есть - тем тяжелее остановиться Си и тем труднее Оберону поехать. А достоинства и недостатки - вторичны в данном контексте, это понимать нужно.

[Alex Rider]

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

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

Ещё какой атрибут. Если C# только под одну платформу, то хоть казачка танцуй, а так оно и есть.

"Под одну палтформу" реализация C# от Microsoft. Язык не может быть платформенно-зависимым в принципе. Так же "невидимая рука рынка" реутомимо указывает, что мощная поддержка C# на куче платформ не нужна. А для Java нужна. И для C/C++ была нужна. Кросс-платформенность в узком смысле подразумевает возможность скомпилить что-то под хотя бы две платформы, в широком смысле - наличие многих проектов под многие платформы. Но, повторюсь - язык - это синтаксис плюс несколько встроенных команд и технологий (сборка мусора, например), и к платформе это все не привязано. Скорее, к кругу решаемых задач.

Указатели на динамические типы в Обероне могут указывать только на эти типы. Есть строгая охрана типов.

Это не спасает от использования "мертвых" указателей и перетирок (собственно, виртуальные машины тоже не спасают от мертвых указателей, только что Access Violation не генерируют). Собственно, код .NET, скомпиленный ngen'ом, тоже нативный, но получает те же сервисы по охране массивов, типов и сборку мусора. Кстати, Оберон-программа на рантайме отслеживает "мертвые" указатели и безопасность преобразования типов?

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

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

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

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

Чем больше и тяжелее поезд - тем тяжелее ему и поехать, и остановиться.

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

[Oleg N. Cher]

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

Если язык реализован на одной платформе и для одной платформы, если поощряет работу исключительно в стиле этой платформы (апи) - все будут писать на нём только под эту платформу. Да этим пользовался ms с первого дня своего шествия.

Это не спасает от использования "мертвых" указателей и перетирок

Что такое "перетирки"?

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

Кстати, Оберон-программа на рантайме отслеживает "мертвые" указатели и безопасность преобразования типов?

Если "мёртвые" - это "зацикленные, указывающие друг на друга", то есть сборщики мусора простые с подсчётом ссылок, эти не отслеживают. Есть более умные, с тегами и отслеживанием от корня. Эти способны корректно освободить и зацикленные структуры.

Безопасность преобразования типов - тоже смотря что ты под этим понимаешь. Кастить тип в другой можно системно: SYSTEM.VAL(новый_тип, что_кастим). Либо же удлинять/укорачивать short := SHORT(long); long := LONG(short), уже несистемно. Переполнение в некоторых реализациях тоже можно отслеживать. Кастить указатель в другой указатель прямо нельзя. Можно "приводить" его к указателю на потомка, и через охранник типа.

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

Мне так и не ответили что за язык есть в нише "безопасность + натив + эффективность". Этот вопрос аккуратно не замечают, наверно он неудобный. Ну ладно, я сам отвечу. Это языки Ада, Модула-3, Оберон, Компонентный Паскаль (какие ещё я упустил?). Причём последние два - для моих задач и целей видятся в гораздо более привлекательном свете. При всех их недостатках - это хорошая база для своего собственного языкостроя.

Могла бы. Ценой "оберега" от всего и вся на рантайме с потерей производительности.

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

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

Зачем тяжёлых, просто изящных. И всё же я хотел бы что-то потяжеловеснее на базе Оберона. Но увы, его просто некому делать, все ещё в Си не наигрались.

P.S.

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

Если хочется аргументов, хороших, веских, не в этом форумном формате, найди в инете книгу Сергея Свердлова "Языки программирования и методы трансляции". Там очень вдумчиво ретроспективно рассмотрена история развития языков программирования от Фортрана и до Оберона. Но заметь, твоё образование только в твоих руках. Если с чем-то не согласишься - я не собираюсь бегать за тобой и что-то тебе доказывать, у меня нет на это времени. Скажу только, что Сергей - прекрасный программист, автор компилятора JOB (Оберон-2 в байт-код JVM), человек безусловно намного более опытный в вопросах программирования и языков, чем три здешних демомейкера, освоивших Бейсик или Си и полтора ассемблера.

[Advertiser]

[marinovsoft]

А есть надежда, что в ближайшее время появится кросс-компилятор (для современных ПК) с Оберона (Оберона-2, Модулы, Модулы-2, паскаля и т.д.) для i8080 ?
А то vinxru забросил свой проект компилятора си.

[dosikus]

но всё же тяжко с тобой говорить, ведь твоя аргументация ...

Ну естественно тяжко, ты же меня напрочь не слышишь , да и куда мне простому смертному до вас небожителей.
Ну да ладно попытаюсь еще раз :
1) Как и писал ранее я не профессионал ,
моя деятельность -фриланс (в свободное от основной работы время )
разработка девайсов малой автоматики на МК.

2) Кодинг для ББ -это не мое, но наляпать несложное интерфейсное приложение для выше-озвученного могу .
3)Ну и плюс хобби - баловство на асме на ZX и Atari .

Ну и далее - дабы не поднимать у тебя ажиотаж, отбрось holly-war и фало-измерительные составляющие и просто ответь:

Что мне даст оберон для пункта 1 и сколько времени займет переход ,
( учитывая что во время перехода мой доход умножится на 0) ?
Кто еще кодит для МК на обероне или же я останусь в гордом одиночестве, ожидая пока кто-то так же прозреет.

[Oleg N. Cher]

А есть надежда, что в ближайшее время появится кросс-компилятор (для современных ПК) с Оберона (Оберона-2, Модулы, Модулы-2, паскаля и т.д.) для i8080 ?

Хороший вопрос. Вероятно, такой надежды нет, нужно садиться и делать самому.

А есть в природе компилятор Модулы-2 или Си (в i8080) для CP/M?

Ну естественно тяжко, ты же меня напрочь не слышишь

А мне сдаётся, что это ты меня не слышишь. Но это неудивительно, мы на разных частотах работаем.

1) Как и писал ранее я не профессионал ,
моя деятельность -фриланс (в свободное от основной работы время )
разработка девайсов малой автоматики на МК.

Для CORTEX'ов/ARM есть парочка компиляторов Оберона-07. Для МК можно разрабатывать и на XDev, только нужно сделать новую подсистему. Это несложно, было бы понимание идеологии XDev и преимуществ Оберона.

2) Кодинг для ББ -это не мое, но наляпать несложное интерфейсное приложение для выше-озвученного могу .
3)Ну и плюс хобби - баловство на асме на ZX и Atari .

Я могу под всё это разрабатывать на Обероне. А вот быстрое зарабатывание денег - с этим у Оберона плоховато, впрочем, как теперь и у Atari/ZX.

Претензии не ко мне, допустим, в музее висит картина и она красива. А тут приходишь ты и спрашиваешь как с её помощью поиметь деньжат. Ну ясно же, что люди говорят на разных языках. Закруглимся.

Что мне даст оберон для пункта 1 и сколько времени займет переход ,
( учитывая что во время перехода мой доход умножится на 0) ?

Нет, наверное Оберон тебе ничего не даст.

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

Иван Денисов кодит, Александр Ширяев. Для CORTEX'ов. Больше таких не знаю, Обероном мало кто занимается.

---------- Post added at 09:29 ---------- Previous post was at 08:30 ----------

marinovsoft,

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

1. Путь более простой, но менее правильный. Найдите самый лучший компилятор Си для i8080 на CP/M, который только есть. Научитесь его запускать в эмуляторе CP/M поверх винды (или линукса). Приделайте к текстовый редактор, запилите библиотек. Можете присмотреться к ZXDev, с помощью неё можно транслировать из Оберона в Си и получить вцелом конфетку. Однако путь тупиковый - можно упереться в какой-то недостаток выбранного компилятора Си и всё пойдёт насмарку. Исправить недостаток в компиляторе без исходников, развивать его - слишком сложно.

2. Это пусть посложнее путь, но правильнее. И есть возможность на внутренней мотивации сделать пользу для огромного числа любителей i8080 во всём мире. Освойте контроль версий (например, Git) - обязательно. Преодолейте барьер и изучите исходники SDCC, особенно как там устроен генератор кода для Z80. Это почти то же, что и 8080, и у вас наверняка уже есть идеи какими аналогами кода заменять команды Z80, которых в 8080 нет. Например, передачу параметров без индексных регистров и т.п. Что-то в этом направлении уже предложил vinxru, и это тоже пойдёт в работу. Компилируйте код, смотрите что получается и заменяйте в кодогенераторе команды Z80 на их аналоги в i8080. SDCC - компилятор оптимизирующий, поэтому он не так прост. Но ничего сверхсложного для грамотного программиста там нет.

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

Вот ещё мысли по поводу создания компилятора для Z80, но всё ровно в той же мере относится и к i8080:

Создание кросскомпилятора языка Оберон для Z80

---------- Post added at 09:32 ---------- Previous post was at 09:29 ----------

Да, а ещё можно выпросить у vinxru исходники его Си и допиливать своими силами. Но это так себе вариант. Просто SDCC гораздо проработаннее.

[marinovsoft]

vinxru говорил, что удалил исходники компилятора. И если он снова возьмется за компилятор, то это будет другой, новый компилятор си.