Мощная среда ZXDev для разработки НА ПЯТИ ЯЗЫКАХ для ZX готова к тестированию

[Vitamin]

Хех. Судя по твоим словам, аффтар открыл делегаты - основную парадигму яблопрограммирования на objc.

От того, что агрегирование используется при реализации делегатов, совершенно не следует, что агрегирование это и есть делегаты.

Я так не говорил. Лучше вдумчиво писать, чем постоянно думать о том, как можно было бы написать. У лентяя всегда инструменты виноваты.

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

Данные и поведение было и до придумывания ООП

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

В том, что программы с ошибками пишутся, чаще всего виноваты люди, а не парадигмы.

Ну кто еще кроме людей-то?
А задача парадигм и прочего как раз сводится к уменьшению человеческого фактора.

[b2m]

Согласен.

[Oleg N. Cher]

Статья интересная, чувствуется интерес автора к вопросу. С итоговыми выводами согласен, а вот с нет промежуточными заявлениями- нет. В частности, предложенная реализация полиморфизма (через if/switch) де-факто таковой не является.

Чудно. Хотел быть тебе полезен, раз ты так интересуешься ООП.

Например?

Я такие вещи плохо запоминаю. А... да. Ну, например, "агрегация". "Code injection". И прочие прелести в том же духе. Главное - звучит очень умно. А программы за программиста сами всё равно не пишутся (а я вижу прогресс именно в этом), только больше сущностей и, закономерно, не только решений, но и проблем, ими порождаемых.

Один из компиляторов поразил меня невозможностью получения указателя на элемент массива, так и сказал: обнаружена "[" вместо ";". Это я к тому, какие интересные бывают реализации "в лоб". FPC тоже примечателен в плане реализации, его исходники открыл... и закрыл. IF THEN ELSE IF на сотни строк, в которые вложены другие IF THEN ELSE IF. В итоге куда там прикручивать кодогенератор так и понял.

Кстати, можно ещё посмотреть Amsterdam Compiler Kit (ACK) - мультиязычную и мультиплатформенную среду разработки.

Мне кажется, FPC лабают (другого слова и не подберу) не ради красоты исходников, просто гонят фичи. А глюки есть практически в любой его версии. Плюс он уже слишком толстый, разросся.

Я не против промежуточной трансляции в Си вообще, но, например, для микроконтроллеров PIC16/PIC18 в таком случае всё упирается в те же уже имеющиеся и не совсем совместимые между собой компиляторы. Ещё и платные. Зачем тогда? Как временное решение для генерации хоть какого-то кода?

Ну да. Иногда результат нужен быстро. Впрочем, даже к платному компилятору нужна заточка Си-генерации до его фич, в зависимости от поддерживаемого стандарта - ISO или там ANSI. ( можно посмотреть PICL: язык программирования для микроконтроллеров PIC - предтеча Оберона ).

Bolt, меня бы очень заинтересовал вот какой компилятор. Мультитаргетный. Использующий в качестве бэк-энда LLVM, GCC или бэк-энды SDCC (там кажется есть PIC?). Хотя в качестве языка я бы предпочёл не Паскаль, а Компонентный Паскаль. Вот это был бы реально интересный инструмент для практической работы. Как раз такой как я делаю через трансляцию в Си. Просто задача слишком сложная. Ведь потом понадобятся к нему IDE, библиотеки, какая-то стыковка с другими средствами и т.д.

Неа. Hisoft Паскаль и ассемблер (Gens) фиговаты, не удобны. Особенно бесит нумерация строк. На их Паскале серьезного ничего не напишешь. Поэтому пишем свои компиляторы.

Всё верно. 7 кб рантайма Hisoft Pascal'я, пристёгиваемые к каждой программе - это ужас. Тип FILE с выводом на ленту, полноценные множества, вещественная арифметика (своя, не из ПЗУ), ввод-вывод (свой) - это явно превращает этот Паскаль в игрушку.

Форт игрушка. Лого игрушка. Сам Спектрум теперь уже игрушка. Причём для "старичков", к которым отношу конечно же и себя.

Andrew771, я бы сделал в компиляторе вариант частичной совместимости с Обероном, включаемый, например, директивой (*$O+*). Который позволил бы не писать лишние begin'ы, включал регистровую чувствительность (повышает аккуратность исходника), ну и некоторые мелкие вещи - типа & вместо AND и # вместо <>. Просто это реально удобные вещи, к которым давно пришёл Вирт (ещё в Модуле-2). Для меня это повысило бы ценность твоего компилятора. Хотя ему ещё предстоит выдержать "сравнение качества кода". С написанным руками на асме.

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

Алекс, не скрою, я конечно надеялся на больший интерес к проекту ZXDev и на коллективную разработку. Но пришлось смириться с умеренным интересом. Что поделаешь. Я не расстраиваюсь. Просто буду разрабатывать другие подсистемы для XDev, вместо ZXDev. Интерес всё равно есть. Или ты предлагаешь закрыть тему и удалить все сообщения?

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

Гораздо важнее для меня другое. Чтобы Оберон не считали давно мёртвым и маргинальным языком, дедушкой Алгола. Кто там интересовался промышленным применением Оберона? denpopov, кажется. Ну вот. Ещё год назад я бы не смог показать вам видео с мероприятия "Оберон-день 2014" в России. И если посмотреть вдумчиво - становится ясно, что эти ребята - не полоумные фанатики и не оригиналы без крыши. Иначе им бы просто никто не доверил разрабатывать серверный софт для АЭС. Они прекрасно разбираются в IT-технологиях, и, в отличии от меня, знают не только плюсы, джаву и шарпы с дотнетами, но ещё и Rust, Go и прочие Lua. Они используют Оберон совершенно сознательно, поскольку понимают его преимущества для своих проектов. А они не в том, чтобы завтра слезть с Оберона в пользу удобных компонентов для отчётов в C#, а в том, чтобы не переписывать завтра систему заново на другом языке. А подтянуть Оберон к своей системе. Под новый проц или новую ОС. Да мало ли...

Встреча поклонников языков программирования семейства Оберон

Дмитрий Викторович Дагаев. Доклад №1: Коммуникационное ПО на языке Оберон для автоматической системы сбора данных на втором энергоблоке Ростовской АЭС.

Евгений Анурин & Павел Маркин. Доклад №3: Автоматизация медицинской лаборатории

Иван Александрович Кузьмицкий. Доклад №6: SDL2.0 как дополнительный слой для портирования Блэкбокса

Интересны конечно и другие доклады, но эти более "промышленные".

[Vitamin]

Я такие вещи плохо запоминаю. А... да. Ну, например, "агрегация". "Code injection". И прочие прелести в том же духе. Главное - звучит очень умно.

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

[denpopov]

мне вот поцстоянно интересно - зачем Vitamin, держит для себя этот трэд? никакой мощьной среды тут и нет в помине.

[Q-Master]

От того, что агрегирование используется при реализации делегатов, совершенно не следует, что агрегирование это и есть делегаты.

Ну таки по твоим словам это и есть открытие делегатов. Закрыть обратно нафиг.

[Advertiser]

[Vitamin]

Ну таки по твоим словам это и есть открытие делегатов.

А перевызов функции- это тоже "открытие делегатов"?

никакой мощьной среды тут и нет в помине.

Ну ты даже такого не сделал. И что? Мне тебя за человека не считать?

[Oleg N. Cher]

Ну что ты, Vitamin. denpopov понимает толк в мощности - мощнее его игры в 512байт я игры не встречал.

Даже боюсь предполагать, что denpopov считает мощьным (в контексте средств разработки для ZX). Вероятно, Alasm. Допросить его с пристрастием нет возможности, но, поскольку сам не говорит какими видит пути умощнения ZXDev, спишем на [beep] - ему ещё учиться и учиться самому пилить для себя dll-ку.

[jerri]

Ну что ты, Vitamin. denpopov понимает толк в мощности - мощнее его игры в 512байт я игры не встречал.

а свои в 512 писал?
скажу по секрету - это сложно

Даже боюсь предполагать, что denpopov считает мощьным (в контексте средств разработки для ZX). Вероятно, Alasm. Допросить его с пристрастием нет возможности, но, поскольку сам не говорит какими видит пути умощнения ZXDev, спишем на beep - ему ещё учиться и учиться самому пилить для себя dll-ку.

Слава Петросяна спать не даёт?
Если бы ты умел смотреть по сторонам, то увидел бы, что denpopov использует sjasm и пишет не только под классику но и под PentEVO TSL edition.

А Аласм на сегодня действительно самый мощный инструмент для реала.
Да и набор утилит

[Oleg N. Cher]

а свои в 512 писал?
скажу по секрету - это сложно

Писал TinyTetris в 2 кб. Представление имею.

denpopov использует sjasm и пишет не только под классику но и под PentEVO TSL edition.

С чуть-чуть другой точки зрения, характерной для 99.9999999% программистов denpopov страдает фигнёй. Впрочем, в мире есть много странных увлечений, например, коллекционирование спичечных коробков.

А вот если бы ты умел смотреть по сторонам, то увидел бы, что инструментов, позволяющих разрабатывать на одном языке для разных платформ, включая ретро, раз два и обчёлся. А я разрабатываю именно это направление. Мне не доставляет сексуального удовлетворения написание игры в 512 байт и демок, наверно в своё время недоездил на пати. Собсно совсем не ездил.

Пока ещё не наигрался разными языками - кажется что ситуация нормальная. Но потом становится ясно: что-то тут не так. Почему, написав единожды хорошую игру, ты постоянно должен её переписывать под каждую платформу? Как-то тебя, jerri, это не колышет? Не видишь смысла? А он есть. И побольше, чем в sjasm'е и в Спеке вместе взятых. Поэтому я в поисках такого единого языка натолкнулся на Оберон. Именно Оберон - кроссплатформенный, универсальный, компактный и простой язык-ядро. А вовсе не Z80-асм, о котором забудут очень скоро. Нужно писать игры, не заморачиваясь на платформу! Оберон рулит.