Мощная среда ZXDev для разработки НА ПЯТИ ЯЗЫКАХ для ZX готова к тестированию [Архив] - Страница 2 - Speccy

Oleg N. Cher

06.10.2014, 16:26

А ты собери мне под debian linux для powerpc процессоров и я попробую это.Q-Master, если хочешь пощупать язык, попробуй Vishap Oberon Compiler (voc):

Свободный (GPLv3) компилятор языка Оберон-2 для GNU/Linux (x86-64, x86, ppc, armv{4-7}). Сделан на базе транслятора Ofront, так что может быть легко перенесён на другие платформы, для которых есть транслятор Си. Содержит набор библиотек, портированных с других реализаций Оберона: ooc, POW!, ETH Oberon, Ulm Oberon System

http://oberon.vishap.am

Возможно на ppc пойдёт Ulm Oberon System?

Oberon compiler for multiple architecture including m68k, SPARC, and x86 under UNIX and GNU/Linux + Ulm Oberon Library

http://www.mathematik.uni-ulm.de/oberon/

Также вот XOberon. Это целая ОС, внутри - компилятор Оберона для ppc:

ОС реального времени для процессоров архитектуры PowerPC, написанная на языке Оберон-2. Разработка Швейцарского института робототехники (EHTZ).

http://www.ifr.mavt.ethz.ch/research/xoberon/

С ZXDev же - увы - никто не будет проделывать такой объём работы, чтобы ты просто "посмотрел". Если тебя интересует Оберон для ZX - должен делать какие-то шаги сам. Я могу только помочь советом. Например, начни с транслятора Ofront (http://www.software-templ.com/shareware.html), собери его для ppc, потесть. Потом прикрути к нему SDCC, собранный для ppc. Удивись как всё вместе работает. Библиотеками можешь пока поживиться с проекта ZXDev. Остальное - то, что на базе BlackBox Component Builder - это IDE, раскраска синтаксиса. Оно может и не нужно тебе. Редактор прикрутишь другой.

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

---------- Post added at 15:26 ---------- Previous post was at 13:58 ----------

Q-Master, в крайнем случае, если не сладишь с Ulm или voc, - можешь посмотреть GPCP (Gardens Point Component Pascal) - диалект (надмножество) Оберона-2:

http://gpcp.codeplex.com

Он для JVM, но это ведь не проблема. Для твоего ppc есть реализация JVM?

А вот инструкция как квикстартовать GPCP под Linux, правда, я пробовал под Ubuntu, а не Debian, но ничего, принцип тот же.

Как работать с Gardens Point Component Pascal под Linux (http://zx.oberon2.ru/forum/viewtopic.php?f=41&t=184)

Eltaron

06.10.2014, 16:42

Кстати, хочу подчеркнуть, что 90% семантики C# взято из Дельфи, да и разработчик тот же. Циферка наобум, но всё же.
10%, и то если за уши притягивать.
C# - это джава, в которой поправили все корявости и вычистили костыли.
Если не нужно париться за производительность, то C# - это просто идеальнейший язык. Компилируемый, строго типизированный (и с выводом типов!), с интроспекцией, с широким применением функционального подхода (о лямбды, как мне вас в джаве не хватает!), с фичами для написания параллельного кода... Безумно красивый и лаконичный язык. Ничего общего с уродливым Delphi.
Единственный ЯП, который сравним по красоте - это эппловский Swift. И то не факт, т.к. на Свифте я ничего не писал, просто прочёл мануал.

Oleg N. Cher

06.10.2014, 20:26

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

Для ZXDev можно же взять C-компилятор для Z80 с открытым кодом и сделать свою ветку со всеми хотелками? Да, но тяжело (в коммерческих условиях это то, что называется "дорого").Можно конечно. Но я соразмерил силы и решил не морочиться с кодогенерацией. Кстати, разработкой SDCC уже много лет занимается больше 20 основных разработчиков, не считая тех юзеров, кто не ленится давать баг-репорты. Оптимизирующий компилятор Си - это слишком сложный проект для маленьких коллективов.

10%, и то если за уши притягивать.Ну бог с вами, пусть будет 10. ;)

C# - это джава, в которой поправили все корявости и вычистили костыли.Ну так и появился позже ведь. И в пику джаве.

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

Eltaron

06.10.2014, 21:22

Кстати, а что такое лямбды что без них жить нельзя? Это как дворецкий, отгоняющий мух и наливающий чай, от услуг которого трудно отказаться? Или как пара гантелей, которая держит в форме твою мускулатуру, но требует ежедневно напряга?
Это новый способ мышления. Возможность изящно описать действие, которое нужно сделать с каким-то списком. Простейшая вещь, которая даёт возможность писать в одну строку то, что без неё писалось бы в 10.

Найти в массиве объект с Id=58
list.First(i => i.Id == 58);

Отсортировать список людей по фамилии, взять первых трех
list.OrderBy(p => p.LastName).Take(3)

Сконвертировать массив строк в массив чисел
list.Select(p => int.Parse(p))

Любая степень вложенности. Найти всех солдат, у которых есть Heavy Laser
list.Where(p => p.Backpack.Any(i => i.Type == Weapon.HeavyLaser))

В тыщу раз короче, чем вложенные циклы+вспомогательные массивы, и в миллион раз понятней.

Это не какая-то свистелка-перделка, это ключевая фича, без которой современный язык не может считаться полноценным. Лямбды есть везде. В C#, python, ruby, C++11. В джаве только нету.

Oleg N. Cher

06.10.2014, 22:21

Спасибо за такое объяснение.

А может быть это достигнуто библиотечным путём? Подобно тому как транслятор функционального или логического ЯП может быть написан на императивном.

Ведь пользуемся мы языком запросов SQL. А программа на Обероне, императивная, описывает, например, данные, т.е. по сути является декларативной.

BEGIN (* Декларируем команды в конфигурационном файле: *)
Lad.Section("[Desktop]");
(*============================================*)
Lad.CmdBool("UseRecycleBin", IsRecycleBin, SetRecycleBin,
Win.IsWinVer( {Win2000..Win2003} ), {Lad.NeedLogOff}
);
...
END Desktop.Нас здесь может смущать только последовательность исполнения. Кстати, на Обероне возможно и мета-программирование. Об этом есть статья Йозефа Темпла, кстати, автора транслятора Ofront.

Alex Rider

06.10.2014, 22:48

Если не нужно париться за производительность, то C# - это просто идеальнейший язык.
Ага. А если нужно париться за производительность, то C# - тоже идеальнейший язык.

А это получается не "иначе", а "всё время". Потому что любая программа зависит от кучи факторов - от стратегии развития ОС, от парка железа и прихотей заказчика. То, что я для краткости называю "конъюнктура". Однако очень заманчиво иметь больше возможностей чтобы контролировать успешность своего проекта.
С первой частью я соглашусь. Действительно, хочется верить, что начатый проект будет всегда развиваться по мере появления новых технологий, и эти технологии будут поддержаны инструментарием. До Delphi 7 включительно у Object Pascal все было с этим хорошо. А вот вторая часть - спорная. Хватит ли сил чтобы поддерживать инструментарий в темпе развития технологий? У Oracle и Microsoft пока хватает, Borland показал, что не справился. Ясно, что, если загнется Microsoft, миллиарды производителей ПО будут мечтать, чтобы их код завтра утром магическим образом перевелся на Java или кросс-платформенную версию C++. В этом смысле, конечно, хорошо иметь "свое". Особенно, если это "свое" не раздуто до размеров слона и поддерживаемо даже в ограниченных условиях. но, повторюсь, стоят ли инструменты коммерческой разработки того, чтобы разрабатывать и поддерживать их самостоятельно? Что будет с проектом если он отстанет от технологий?

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

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

---------- Post added at 22:48 ---------- Previous post was at 22:46 ----------

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

Oleg N. Cher

07.10.2014, 00:42

Значит это может быть достигнуто путём использования встроенного интерпретатора, но написанного библиотечным способом. Я начинаю думать, что лямбда-исчисление доступно для Оберона. Вот смотрите, возьмём для примера BlackBox Component Builder. В нём есть подсистема Dev, содержащая компилятор Компонентного Паскаля. Он вызывается с помощью команды активации компиляции из меню. Не составит никакой проблемы вызывать компилятор из своего собственного модуля. Не составит и никакой проблемы переориентировать компилятор брать входной текст (на Компонентном Паскале) не из текстового окна, а прямо из вызывающего кода. Это может выглядеть так (код условный):

MODULE Lambda;

IMPORT Dev, Kernel;

CONST
MyCode = "MODULE MyCode; IMPORT Out; BEGIN Out.String('Hello, integrated World!') END MyCode;";

BEGIN
Dev.CompileText(MyCode);
Kernel.LoadModule("MyCode");
Kernel.RunModule("MyCode");
END Lambda.

Данный подход конечно пользуется компилятором и ядром, но зато - никакой интерпретации.

---------- Post added at 23:42 ---------- Previous post was at 22:10 ----------

Так можно сделать лямбды если они понадобятся оберонщику. Мне пока не понадобились. Наверное я не очень продвинутый.

Просто Дельфи- или Си-программист воспринимает компилятор как нечто совершенно отчуждённое от его личного кода. В Оберон-системе компилятор - такой же компонент, как и любой другой. И точно также ему можно посылать сообщения и получать ответы. Точно так же обстоят дела и с IDE, документами, окнами и любыми другими контролами.

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

Eltaron

07.10.2014, 15:40

Это может выглядеть так (код условный):
А указатели на функции в Обероне есть? Скомпилировать в рантайме кусок кода - это одно дело, но его же надо ещё и передать в функцию, выполняющую сортировку или поиск.
В любом случае, когда код записан строкой - он не типобезопасен. Он вообще не безопасен, там и опечатки могут быть, и что угодно ещё. В C# и C++11 очень круто то, что все эти конструкции проверяются ещё на этапе компиляции.

Alex Rider

07.10.2014, 17:50

Так можно сделать лямбды если они понадобятся оберонщику.
Так в них теряется смысл. Потому что выражение i => i.Id == 58 лаконично и понятно. Ты же не напишешь код запуска компилятора в качестве фактического параметра? Тогда зачем оно вообще нужно? Кстати сказать, лямбда-выражения в основном применяются к generic-коллекциям, без них я тоже от лямбд смысла не вижу.

Мне пока не понадобились. Наверное я не очень продвинутый.
А мне пока ЯВУ (кроме Бэйсика) для Спектрума не понадобились. Представляю себе свой уровень в сравнении... Тебе не понадобились потому что не пробовал. :)

AlexG

08.10.2014, 10:55

Общий вопрос:
Как обстоят дела с INTEGER 64bit в языке ОБЕРОН ?
Коим образом можно "перенести" работу с битовыми полями с С на Оберон ?
Как обстоят дела с объединениями ?
union {
u16_t var1;
struct {
u8_t aaa;
u8_t bbb;
}
}

var1 = 0x1122;
tmp = aaa + bbb;

Oleg N. Cher

16.10.2014, 18:19

А указатели на функции в Обероне есть?Конечно есть:

PROCEDURE Fn(): INTEGER; BEGIN RETURN 0 END Fn;
...
VAR fn: PROCEDURE (): INTEGER;
BEGIN
fn := Fn; ...
...
END ...

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

Я опасаюсь, что ново-программисты будут использовать такое средство как лямбды, для которого конечно можно придумать хорошее применение, втуне. Т.е. не понимая чётко всего механизма. А оно как - компилируется? А потом? Куда-то загружается и запускается? Т.е. вся эта тянучка из компилятора и рантайма присутствует в конечном продукте. И накладные расходы соответствующие. Для сортировки списка или поиска элемента - это уже слишком.

Как обстоят дела с INTEGER 64bit в языке ОБЕРОН ?В зависимости от реализации. В стандарте Оберона/Оберона-2 размеры типов не зафиксированы. Традиционно (ETH Oberon, A2/AOS, XDS) INTEGER = 16 бит; LONGINT = 32 бита. Для 64 битов в некоторых реализациях есть тип HUGEINT.

В Component Pascal, XDev/WinDev INTEGER = 32 бита; LONGINT = 64 бита. Есть ли возможность использовать именно 64-битный INTEGER? В XDev/WinDev - да. Размер всех типов задаётся в специальном файле-конфигураторе Ofront.par, выглядящем примерно так:

CHAR 1 1
BOOLEAN 1 1
SHORTINT 2 2
INTEGER 4 4
LONGINT 8 8
SET 4 4
REAL 4 4
LONGREAL 8 8
PTR 4 4
PROC 4 4
RECORD 1 1
ENDIAN 1 0

Коим образом можно "перенести" работу с битовыми полями с С на Оберон ?Для работы с битовыми полями предлагается тип SET, что во многом снижает потребность в логических операциях AND, OR, XOR. Несмотря на некоторую громоздкость записи, логические операции для целых в Обероне всё-таки можно использовать.

Вирт Н. SET: Недооцениваемый тип данных и его компиляция для ARM (http://oberoncore.ru/library/wirth_sets)

Как обстоят дела с объединениями ?
union {
u16_t var1;
struct {
u8_t aaa;
u8_t bbb;
}
}

var1 = 0x1122;
tmp = aaa + bbb;Объединения в Оберон-парадигме считаются опасным низкоуровневым средством. В некоторых реализациях есть возможность использовать объединения в биндингах (например, в BlackBox).

Какая альтернатива предлагается для замены объединений? Расширяемые записи.

TYPE
Father = (*EXTENSIBLE*) RECORD
a, b, c: INTEGER; (* Это общие для всех потомков поля *)
END;
Son = RECORD (Father)
d, e: CHAR; (* Это только данные сына *)
END;
Daughter = RECORD (Father)
d, e: SET; (* Это только данные дочери *)
END;
Оберон строг в проверке типов и на этапе компиляции, и в рантайме. Он спроектирован так чтобы по максимуму обезопасить работу с указателями. Соответственно нет смысла кастить объект типа Son в объект типа Daughter и пытаться работать с полями сына как с полями дочки. Вместо этого применяется охрана типа:

obj: POINTER TO Father; (* Это указатель на отца и др.членов семьи *)
BEGIN
IF obj IS Son THEN ... END; (* Проверка того, что это сын *)
WITH obj: Daughter DO (* Гарант того, что объект - дочь *)
(* Если объект не дочь - ловится ошибка исполнения или исключение *)
END

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

В принципе, мне объединения ещё ни разу не понадобились, кроме как в биндингах к SDL 1.3 (там есть их два штуки).

Хочу подчеркнуть, что Оберон - маленький язык. Если хочется увидеть в нём прямые аналоги всех сишных возможностей, то этого нет. Но зато, например, компилятор ARM Oberon-07 занимает ~ 3 000 строк исходника. OP2 (Oberon Portable Compiler) ~ 10 000 строк.

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

Alex Rider

16.10.2014, 19:49

Я опасаюсь, что ново-программисты будут использовать такое средство как лямбды, для которого конечно можно придумать хорошее применение, втуне. Т.е. не понимая чётко всего механизма. А оно как - компилируется? А потом? Куда-то загружается и запускается? Т.е. вся эта тянучка из компилятора и рантайма присутствует в конечном продукте.
Плохой программист будет одинаково плохо использовать возможности любого языка/библиотеки. Бояться тут нечего. Многократно убеждался, что на более простых языках *****кодить можно с большим успехом.

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

Но зато, например, компилятор ARM Oberon-07 занимает ~ 3 000 строк исходника. OP2 (Oberon Portable Compiler) ~ 10 000 строк.
Это, вероятно, есть плюс для маломощных компьютеров.

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

Oleg N. Cher

16.10.2014, 22:49

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

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

Я бы сказал, что Оберон - это наиболее простая из современных прослоек между машинными кодами и человеческим мышлением. Притом в сторону человека. Спорить об этом можно, но мы исходим из разных позиций. Тебе надо абы быстро домой, а я занимаюсь свободным творчеством. Вообще очень сложно сравнивать Оберон и C#. Потому что я беру Оберон как нотацию для записи алгоритмов. А ты берёшь C# как готовое и очень проработанное средство для коммерческого программирования. Мы говорим абсолютно на разных языках. И исходя из абсолютно различных потребностей.

Это, вероятно, есть плюс для маломощных компьютеров.Ceres, на котором была запущена первая Оберон-система (ETH Oberon), если я не запамятовал, имел 1 Мб ОЗУ. JVM или .NET в таком объёме вообще не выстрелят. Но плюс не только в экономности. Плюс в простоте и скорости переориентировки. Я упомянул 3 000 строк кода. Допустим, замысел .NET как многоязыковой платформы не вполне удался, а микрософту это и не было особенно нужно. Это действительно так - все используют преимущественно C#. Да, можно писать для .NET и на Компонентном Паскале, но кто это делает? Фактически .NET моноязычен. И C# - язык одной платформы - .NET. Допустим, платформа провалилась. Все в массовом порядке ломанулись переписывать свой код, если он, разумеется, ещё актуален. На язык, который пропихивает какая-то новая фирма, например, гугле. Вместе с тем, появилась новая архитектура, допустим, мобильная, со своим другим языком. Оберонщик со своим кодом просто перепишет свой компилятор Оберона на другую архитектуру. И его код будет актуален. Возможно, это достоинство не покажется тебе таким уж существенным. Но это повышает ценность нашей работы. Она не нивелируется с провалом того слоя, на котором целиком она была выстроена. А слой, на который мы сделали ставку, весьма мал и подъёмен. И даже относительно независим от нижележащей архитектуры.

Я бы подчеркнул, что средства в духе XDev, Haxe и Monkey-X, о которых я упоминал, - это реакция программистов на множество языков, платформ и архитектур. И на их бурную, но недолгую жизнь. Это реакция не огромных фирм, которым надо запустить свою машину, чтобы все потом пришли к ним и работали на их средствах. А они просто определяли дальнейшую стратегию их развития. И пожинали плоды (кто девушку гуляет - тот её и танцует; также и юзверей имеет).

Философия Оберона - ничего лишнего. Если тебе это по вкусу, то это для тебя. Мне это не совсем по вкусу, я не такой большой минималист и очень болезненно воспринимаю урезанность такого диалекта как Оберон-07. Мне он кажется очень сильно минималистичным. Поэтому я взял Оберон-2 и Компонентный Паскаль за основу своего диалекта. И наращиваю его возможностями, которые мне кажутся необходимыми.

Alex'у G, если он хочет слезть с Си, вероятно, лучше подойдёт Modula-2, в которой есть тип BITSET и объединения. Хотя я забыл упомянуть о низкоуровневых возможностях Оберон-реализаций, которые даже не стандартизированы. Всё перечисленное может быть реализовано с их помощью. В первую очередь это конечно возможности низкоуровневого псевдомодуля SYSTEM - SYSTEM.PUT(adr, value), позволяющая заслать по любому адресу простую переменную любого типа. Так что, получив адрес записи с помощью SYSTEM.ADR(rec), мы можем спокойно записывать по любому смещению от него любое значение. Но Оберон не очень поощряет такой стиль. Мне особенно нравится, что низкоуровневые моменты в Обероне обычно очень изолированы от остального кода. И проще отслеживать ошибки в них. А вспомним, основные претензии сишников к Оберону "а тут низя по этому адресу поместить вот этот массив байтов". Конечно низя! Но если очень надо, то мона. ;) Зато когда будешь переписывать это - увидишь что все низкоуровневые приблуды у тебя в одном модуле как-то сами сконцентрировались. И не очень этот модуль и большой. Переписал его - и порядок. А высокоуровневый слой настолько хорошо проработан, что его мало колышет даже разрядность ОС.

Для вкуривания в философию Оберона предлагаю пробежать глазками статьи на сайте compact-programming.narod.ru (http://compact-programming.narod.ru). Если вставляет - значит тема, иначе не стоит Оберон юзать.

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

Alex Rider

18.10.2014, 15:46

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

Массив это точно массив. А не адрес, к которому можно по ссылке обращаться.
А что значит "массив - не адрес"? То, что он всегда в стеке живет, а не в динамической памяти? Ну так это ограничение жесткое, а не благо. Разработчику в 99% должно быть пофиг как организован массив внутри, зато не пофиг на максимально возможный размер этого массива.

Зато внутренне выглядеть это будет статически скомпилированным. А не тянущим за собой бог весть какой рантайм.
Рантайм тянут не лямбда-выражения, это - неотъемлемая часть .NET и Java, дающая много полезных плюшек для коммерческой и любительской разработки. Про скорость разработки этого я уже писал. Про сложность понимания такого кода, думаю, писать не имеет смысла. И да, лямбда-выражения тоже статически компилируются.

Программист не представляет что в них происходит.
Хороший программист представляет.

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

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

Потому что я беру Оберон как нотацию для записи алгоритмов. А ты берёшь C# как готовое и очень проработанное средство для коммерческого программирования.
Оно и то, и то есть нотация для записи алгоритмов. Но да, я соглашусь, что C# удобнее для быстрой и дешевой коммерческой разработки. А для души можно и на Brainfuck писать, это не принципиально.

Ceres, на котором была запущена первая Оберон-система (ETH Oberon), если я не запамятовал, имел 1 Мб ОЗУ. JVM или .NET в таком объёме вообще не выстрелят. Но плюс не только в экономности.
Я согласен, что языки с виртуальными машинами для "больших" систем.

Допустим, замысел .NET как многоязыковой платформы не вполне удался, а микрософту это и не было особенно нужно.
Наличие дестяков (https://ru.wikipedia.org/wiki/%D0%A1%D0%BF%D0%B8%D1%81%D0%BE%D0%BA_.NET-%D1%8F%D0%B7%D1%8B%D0%BA%D0%BE%D0%B2) .NET-языков (в том числе, и детищ Borland с о.NETчиванеим VCL) как бы опровергает этот факт. Micfosort'у надо, чтобы покупали Visual Studio.

Да, можно писать для .NET и на Компонентном Паскале, но кто это делает? Фактически .NET моноязычен. И C# - язык одной платформы - .NET. Допустим, платформа провалилась.
Ну как минимум VB.NET- и Object Pascal-проекты достаточно популярны.

Допустим, платформа провалилась. Все в массовом порядке ломанулись переписывать свой код, если он, разумеется, ещё актуален. На язык, который пропихивает какая-то новая фирма, например, гугле. Вместе с тем, появилась новая архитектура, допустим, мобильная, со своим другим языком. Оберонщик со своим кодом просто перепишет свой компилятор Оберона на другую архитектуру. И его код будет актуален.
Да, подобная штука случилась с Delphi и создала проблему разработчикам. Но у Delphi не было пригодных для использования аналогов. Гарантировать, что Windows + .NET + C# не загнется, конечно, не могу, но C#, как удачный язык, имеет не одну IDE (в том числе, бесплатные) и работает не для одной платформы, так что шансы напороться на фокус, аналогичный Borland'овскому, существенно ниже.

Оберонщик со своим кодом просто перепишет свой компилятор Оберона на другую архитектуру.
На данный момент, напомню, ZXDev не компилит из Оберона в машкод. Так что "просто" не переписывается. А компиляция-через-С доступна для любого языка.

Я бы подчеркнул, что средства в духе XDev, Haxe и Monkey-X, о которых я упоминал, - это реакция программистов на множество языков, платформ и архитектур. И на их бурную, но недолгую жизнь.
C и UNIX как бы опровергают тезис про "бурную, но недолгую жизнь" всех без исключения платформ и языков.

Философия Оберона - ничего лишнего. Если тебе это по вкусу, то это для тебя. Мне это не совсем по вкусу, я не такой большой минималист и очень болезненно воспринимаю урезанность такого диалекта как Оберон-07. Мне он кажется очень сильно минималистичным. Поэтому я взял Оберон-2 и Компонентный Паскаль за основу своего диалекта. И наращиваю его возможностями, которые мне кажутся необходимыми.
Означает ли это, что семейство Оберон-подобных языков древовидно, при этом код на языках с "соседних" уровней несовместим?

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

Oleg N. Cher

19.10.2014, 01:40

Мне немного непонятно ради чего ты тратишь время на наш диалог. Либо "хочу лучше узнать Оберон", тогда почему бы чего-нить про него не прочитать? Либо "навожу порядок в мозгах Oleg'а N. Cher'а, которые мне кажутся вывихнутыми, но зато публика меня читает". Но да ладно, продолжаем.

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

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

Позволь простой пример. Сишник пишет:

void fn() {
int *a; a = 1234; *a = 1234; // я выстрелил себе в ногу - ура!
}Это парадигма Си. И половина читающих этот пост сишников будет с умилением радоваться возможностям такого кодинга - потому что это свобода. Как на асме. На Обероне без импорта псевдомодуля SYSTEM нельзя так сделать. Недостаток? С точки зрения сишника - огромный.

А почему Си не взлетел для веб-программирования? Наверное потому что строки в нём не так удобно обрабатывать? Да нет, ничего подобного. Потому что стиль такого кодинга, каковой показан выше, прочно вгрызся в эту парадигму. Менять ничего нельзя, исправлять-дополнять - тоже. Совместимость важна. Комом растут возможности. Есть, правда, повод откреститься от части устаревших средств с выходом нового стандарта, но и здесь есть проблемы. Мне в связи с этим нравится подход Оберон-парадигмы. Подмножество Оберон-1 - общее для Компонентного Паскаля, Активного Оберона, Oberon-X и ещё пары меньше известных диалектов. Соответственно, модуль на первом Обероне - кандидат на переносимость между диалектами. Нужны возможности - позиционируем новый диалект с полной или частичной поддержкой какого-то из существующих. Всё делается чётко под задачи. Ненужные, опасные устаревшие, возможности исчезают из языка. Про переписывание программ я знаю, но язык остаётся живым, а не покрывается плесенью, а как же.

Так вот для веб-программирования важна безопасность. Чтобы ошибка кодера веб-сайта не завешивала намертво комп посетителя сайта. И чтобы злонамеренно не тырили его данные. Нужны ограниченные языки. Привносится виртуализация, это более или менее понятно. Как бы можно было сделать на Обероне? Очень просто - запретить приходящим из инета модулям импортировать SYSTEM, а в качестве обвязки - разрешить только безопасные средства, препятствующие вредоносной деятельности. Если нужно ограничить память под работу этого модуля - опять же, нет проблем - в ядре прописывается квота.

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

А что значит "массив - не адрес"? То, что он всегда в стеке живет, а не в динамической памяти?Неверно.

Живёт он и в динамической если динамически выделен, и в статической - если статически. Массив не адрес - в понимании программиста. Адрес массива получить легче лёгкого. Я уже писал про SYSTEM.ADR, так оно для этого хорошо подходит. Массив не адрес в том смысле, что в голове у разработчика нету путаницы передачи по ссылке или же указателя.

И конечно же разработчику на Обероне пофиг как организован массив внутри, зато максимально возможный размер массива он может получить с помощью:

LEN(mas)

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

Про brainf*ck не будем, мы про языки для разработки, а не для выноса мозга.

Oleg N. Cher

19.10.2014, 02:12

Хороший программист представляет.Да распрекраснейший в мире программист не представляет в какой именно момент поступит прерывание. Тебя никогда не удивляла логика работы твоего кода по мере его отладки? О, тогда ладно. ;)

Простая технически - слоглашусь. Простая для эффективной разработки - вряд ли.Твоя "эффективная" разработка - она в первую очередь в той среде, в которой ты умеешь работать. Ручаюсь, я освою IDE сишарпов куда быстрее, чем ты интерфейс ETH Oberon. ;) Оберон меня положительно удивлял, а иногда даже очень сильно. Просто я до этого на Си и Дельфи много работал. Удивлял не тем, что автодополнял в текстовый редактор окончание метода, а тем, что избавлял от таких ошибок, которые я раньше ловил, бывало, целую неделю. При всей своей непритязательности - разрыв между средствами огромный - я понимаю что Оберон - это ядро, для насаживания на него дальнейших возможностей. Ядро моего идеального императивного языка. Оно минимально конечно, но в этом и минусы, и плюсы. Я сейчас имел ввиду, скорее, не Оберон, а Компонентный Паскаль.

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

Наличие дестяков (https://ru.wikipedia.org/wiki/%D0%A1%D0%BF%D0%B8%D1%81%D0%BE%D0%BA_.NET-%D1%8F%D0%B7%D1%8B%D0%BA%D0%BE%D0%B2) .NET-языков (в том числе, и детищ Borland с о.NETчиванеим VCL) как бы опровергает этот факт.Да знаю я про эти языки. Однако кого ни спрошу - на C# строгает. Ничего другого не приемлют. Даже в связке с C#. А кто-то из шарпачей сказал, что C# идеально использует возможности рантайма .NET, другим языкам это вроде как не очень удаётся.

шансы напороться на фокус, аналогичный Borland'овскому, существенно ниже.По моему скромному мнению Дельфи это замечательная среда разработки. При этом я имею ввиду где-то Дельфи 6-7. Туча недостатков, некроссплатформенный. Потом правда это маленько поправили в FreePascal. Но этот Титаник всё-таки слишком огромен. Я делал на нём софт для клиентов и остался удовлетворён. Быстро работается, удобно, много информации. Но переориентировать его не так было просто. Оберон (опять Компонентный Паскаль) - сильно проще. Поэтому моя ставка - на него. Но с Дельфи - масса общего, очень. Просто сильно уменьшенный язык.

На данный момент, напомню, ZXDev не компилит из Оберона в машкод.Можно интимный вопрос? ;) Тебе не всё равно каким образом получается там машкод? "Раз не натив, значит смотреть не буду" - позиция понятна, даже с сочувствием. Но я по правде говоря сильно надеялся на поддержку. А так - приходится всё делать самому. Направление ZXDev я сейчас почти и не трогаю. Может ковырну, если будет настроение. Не нужно никому. Скукота.

Так что "просто" не переписывается.А кто-то пробовал? И поясни, пожалуйста, смысл заниматься такой работой для получения компилятора, который делает то, что умеет SDCC, только намного хуже. К коду придирок будет столько - все в какашках утонут. Зато прямо в натив, та божежмой какое щастье! ;)

А компиляция-через-С доступна для любого языка.Ну это как сказать.

C и UNIX как бы опровергают тезис про "бурную, но недолгую жизнь" всех без исключения платформ и языков.Как бы UNIX менялся. И Си менялся. Это просто название осталось. Сам предмет же - менялся много раз. И на него делали и продолжают делать ставку, делают надмножества - Титаники. C++, Objective C. Нормально получается, многим ничего лучше и не нужно. Но я читал хорошие статьи, разговаривал с людьми, писал код и думал. Я хорошо понимаю недостатки Си. И говорю об этом не затем, чтобы сказали что я голословно обсираю Си. Нет. Си неплох. Просто на своём месте.

UNIX просто был раньше других портабельной ОС. Впрочем, взять Linux. Что было бы если бы Торвальдса заинтересовал, например, ETH Oberon? Ничего не было бы. Торвальдс сделал ставку на юзеров в первую очередь. А даже не на программеров. ZXDev сделал ставку на ностальгирующих кодеров, 90% из которых ничего кроме асма не признаёт, а другие просто уже не кодят. Да и первые тоже. Короче говоря, делай всё сам и нам показывай. Да без короны. Иначе не так поймём. Господа, я не хочу ничего делать, делайте сами, если вам нужно.

Означает ли это, что семейство Оберон-подобных языков древовидно, при этом код на языках с "соседних" уровней несовместим?Да их не так и много, диалектов. Да и про совместимость мало кто думает. Ну вот зачем тебе совместимость твоего проекта с AOS если ты делаешь проект под ядро BlackBox? Она возможна, но зачем трудиться понапрасну. Есть веб-сервер O3, совместимый с GPCP и BlackBox, собирается под Windows, .NET и JVM (если бы мне пришлось разрабатывать подобный проект - я бы выбрал только Компонентный Паскаль - не знаю ничего аналогичного).

Но вот зато ковырялся в исходниках на Амига-Обероне, парочку скомпилил в XDev без проблем. Правда, пришлось кое-что по мелочёвке поменять - & вместо AND, например. Хотя размер типов разный. Вобщем, о формальной совместимости между диалектами речи нет. Они и создавались обычно под разные нужды. И средства для биндингов в них реализованы разные. GPCP, к примеру, нужно биндить под JVM .class-ы, а XDS - под WinAPI.

Ну, если ты не живешь на наследство богатого дяди, то тебе приходится зарабатывать чем-то деньги и тоже быть невольником.Богатого дяди нет, не завидуй. ;) Работаю тоже по компьютерной части, но без программинга. Можно сказать "что-то типа админ". Думаю, если бы работал программистом - не было бы духу на хобби, все мозговые ресурсы забирали бы рабочие проекты. Свойство профессии - трудно переключаться между разными проектами.

При этом и я, и работодатель, и заказчики как правило выбирают для разработки наиболее подходящий для задачи язык, а не тот, который знает некий Вася Пупкин, принимающий решенияХорошо если хоть программисты выбирают, а не дядя манагер, который краем уха слышал, что M$ - это круто.

Alex Rider

20.10.2014, 20:59

Да распрекраснейший в мире программист не представляет в какой именно момент поступит прерывание. Тебя никогда не удивляла логика работы твоего кода по мере его отладки? О, тогда ладно.
Олег, не подменяй понятия. Мы говорили о понимании работы конструкций языка на примере лямбда-выражений. Причем тут прерывания? Хороший программист представляет себе то, что делает компилятор с его исходником и понимает как это должно работать. А мои результаты отладки - да, удивляют и смешат, я тоже делаю ошибки в коде и считаю, что язык с богатыми и удобными возможностями помогает делать их меньше, а находить быстрее.

Твоя "эффективная" разработка - она в первую очередь в той среде, в которой ты умеешь работать. Ручаюсь, я освою IDE сишарпов куда быстрее, чем ты интерфейс ETH Oberon.
Не правда. После некого погружения в действительно удобную среду начинаешь писать на ней быстрее. Был опыт перехода с Delphi 7 на C# (MSVS 2005) - Delphi, котрую я знаю наизусть, кажется мне ужасом тихим - в ней ничего не удобно. Письками меряться не будем - у меня работа заключается в быстром освоении незнакомых софтин :) И IDE Visual Studio была не самой простой их них из-за больного количества возможностей. Что не значит, что пока их не выучишь, писать не сможешь.

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

По моему скромному мнению Дельфи это замечательная среда разработки. При этом я имею ввиду где-то Дельфи 6-7.
Delphi сильно отстала от жизни.

Но переориентировать его не так было просто. Оберон (опять Компонентный Паскаль) - сильно проще.
Проблема Delphi не в языке. А в инструментах для создания приложений - отладчика, компилятора, мастеров, шаблонов, библиотек. Посему преимуществ урезанных языков я тут не вижу.

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

И поясни, пожалуйста, смысл заниматься такой работой для получения компилятора, который делает то, что умеет SDCC, только намного хуже.
"Намного хуже" - это не однозначно. Тема эта очень большая. Из самого простого - упрощение IDE (в идеале - IDE.exe, которая дает на выходе bin, hex, tap, trd, spg), что психологически проще. Компилятор простого языка, вероятно, будет давать более эффективный код. Независимость от команды разработки SDCC - тоже плюс. Подсознательное ощущение, что каждая лишняя трансляция убивает производительность тоже играет вовред ZXDev.

Короче говоря, делай всё сам и нам показывай.
Да, в общем-то, и показывать даже не требуем :)

Как бы UNIX менялся. И Си менялся. Это просто название осталось.
Такое ощущение, что они менялись кардинально. C++ и Objective C - это совсем другие языки с C-подобным синтаксисом. Для самого C вышло несколько стандартов, которые не перепахивали язык до неузнаваемости. Ядро Linux медленно эволюционирует, хотя дистрибутивы его отличаются, да, за счет пакетов. Идеология UNIX практически не меняется.

Ну вот зачем тебе совместимость твоего проекта с AOS если ты делаешь проект под ядро BlackBox?
Потому что, например, разработчик одного из диалектов (вместе с IDE) объявит о завершении поддержки из-за свадьбы/рождения ребенка/банкротства/ядерной войны, его язык и среда устареют и надо будет переползать на современный развивающийся аналог.

Хорошо если хоть программисты выбирают, а не дядя манагер, который краем уха слышал, что M$ - это круто.
Нет, не хорошо, когда программисты выбирают. Потому что они выбирают то, что знают, а не то, что подойдет. Хорошо, это когда манагер, принимающий решения, технически подкован, разбирается в предмете и сравнивает инструменты по характеристикам и условиям работы компании, без личных предпочтений.

---------- Post added at 20:59 ---------- Previous post was at 20:58 ----------

Чот тема стала похожа на соревнование "у кого длиннее" (я про посты).

Oleg N. Cher

22.10.2014, 22:21

Олег, не подменяй понятия. Мы говорили о понимании работы конструкций языка на примере лямбда-выражений. Причем тут прерывания?Ага, тоесть программист таки понимает зачем он использует лямбды. Ну, браво. Но я слегка не об этом. Проблема избыточной сложности программных систем. Прерывания - это так, чепушинка. Современный новопрограммер может не понимать код "в глубину", не представляет как устроена его ОС и его процессор. Ты можешь сказать, что этого всего и не нужно. Вероятно, всё и не освоить. Но альтернативой сложной системе и сложному языку я бы назвал простые систему и язык. Самая большая проблема сложного языка и системы - склонность быть "Титаником". И в какой-то момент не смочь повернуть и увернуться. Примеров хоть сколько угодно. ОС Windows, архитектура 80x86, плавно перетекающая в x64. UNIX и Linux. Ну да, Си держит UNIX на плаву, UNIX держит Си, однако постом выше я показал несостоятельный момент Си, который несмотря на всю плавучесть Си уже готовит ему гробик. В этом свете C# и Java не могут окончательно вытеснить Си (пока что) - потому что это виртуальные платформы, а люди ещё не отвыкли от натива. Ну ничего, помаленьку отвыкнут.

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

Сложный IDE C#, напичканный возможностями, впечатляет беднягу программиста. Тебя должно порадовать то, что скоро бедняге нужно будет забыть то, что он умел и начать всё сначала. Потому что выбирает-то не программист, а манагер. ;)

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

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

"Намного хуже" - это не однозначно.Чтобы догнать наш гипотетический компилятор до уровня SDCC - нужна отмотивированная команда талантливых и заинтересованных разработчиков. Хотя бы человек 3-5.

Тема эта очень большая. Из самого простого - упрощение IDE (в идеале - IDE.exe, которая дает на выходе bin, hex, tap, trd, spg), что психологически проще.Смотря кому проще. Мне психологически проще знать, что я завтра прикручу к своему XDev библиотеку на Си и модуль на асме, и не буду париться с закрытой средой, которая работает как чёрный ящик и в которой непонятно что происходит. Люблю, понимаешь, открытость и лёгкость интеграции с чем-то очень хорошо обжитым.

У меня, в принципе, готов XDevLite, который представляет из себя как раз один exe'шник. И всё примерно как ты говоришь, только ессно SDCC идёт всё-таки отдельным exe'шником. Не вижу смысла его впихивать. Ну и подсистема ZXDev, само собой, в виде многих файлов. Тоже не вижу смысла пихать их внутрь exe'шника. Разве что инсталятора.

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

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

Кстати, здесь было замечено, что коммерческие фирмы, дескать, юзают Оберон потому что так сложилось. И мечтают с него слезть в сторону .NET. Что же, можно сказать определённо, что человек, перед которым стоит выбор C++ или C# - не выберет Оберон с дурной башки. Просто потому что ему это не придёт в голову. Оберон выбирают те, кто верит в эту технологию и знает её хорошо. Это обычно те программисты, которые закончили ETH, слушали лекции Вирта и Гуткнехта. Я знаю примеры. Так что здесь выбор Оберона не случаен. И слезть с него потом никто не планирует и не мечтает. Это сознательный выбор подкованных фундаментальным образованием в области информатики программистов.

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

Независимость от команды разработки SDCC - тоже плюс. Подсознательное ощущение, что каждая лишняя трансляция убивает производительность тоже играет вовред ZXDev.Это от непонимания логики работы ZXDev. Которое надо лечить просвещением, но никак не потаканием.

Да, в общем-то, и показывать даже не требуем :)Это jerri требовал. Сам для себя он считает возможным делать чего хочет, чего угодно хвалить и чего угодно обсирать. Мне же предписывал появиться на задних лапках, но без короны, и начать всех удивлять крутыми играми на Обероне. Я мож бы и поступил так, но проекты всё долгоиграющие, а поддержки никакой, даже моральной.

Oleg N. Cher

23.10.2014, 00:59

Вы смотрели потрошка .NET? Беру файл dotnetfx35.exe, захожу в него в TC по Ctrl+Dn:

\dotnetfx35.exe\wcu\.\.\.\.\.\dotNetFramework\dotN etFX20\
\dotnetfx35.exe\wcu\.\.\.\.\.\dotNetFramework\dotN etFX30\
\dotnetfx35.exe\wcu\.\.\.\.\.\dotNetFramework\dotN etFX35\
\dotnetfx35.exe\wcu\.\.\.\.\.\dotNetFramework\dotN etMSP\
\dotnetfx35.exe\wcu\.\.\.\.\.\dotNetFramework\Tool s\
\dotnetfx35.exe\wcu\.\.\.\.\.\dotNetFramework\dotN etFx35setup.exe

Как видим, .NET 3.5 представляет из себя ровно всю плеяду дотнетов предыдущих версий, непонятно только куда подевался 1.1. Теперь можно порассуждать про экономное использование ОЗУ за счёт повторного использования компонентов и библиотек. Т.е. пользуясь технологией .NET вы получаете снежный ком, который в один прекрасный момент безусловно рухнет под собственной тяжестью. Впрочем, может всё ещё закончился красиво, поддержка 2.0 и 3.0 будет постепенно убрана. Но не расслабляйтесь пока, решать это не вам, а могучему m$.

Оберон-парадигма, как мне кажется, предлагает несколько другой путь (очень хочется в это верить). Лодка не плывёт далеко, хотя Бомбаров это не смущает, но она за счёт своей лёгкости меняет курс быстрее Титаника. Но грести приходится всё-таки ручками, на что многие обижаются. Можно конечно прицепить мотор, но уже требуется топливо и теряется совместимость с весельной версией лодки. ;)

Расскажу ещё байку про дотнет из книги Сержа Тарасова "Дефрагментация мозга. Софтостроение изнутри" (http://itknigi.net/programmirovanie/programming/4088-defragmentaciya-mozga-softostroenie-iznutri.html). Сама книга мне очень понравилась. Байка же, как мне кажется, иллюстрирует недостатки "титанического" подхода.

Когда старая школа молода

Изменения происходят столь быстро, что приходится записывать в ряды старой школы системы с приложениями на последних версиях автономного Visual Basic 6, безвозвратно растворившегося в бурлящей пучине. NET. Теперь, спустя немногим более десяти лет, когда начинают всплывать проблемы с поддержкой из-за отсутствия специалистов, принимаются решения о переделке систем в новой технологии с минимальными изменениями функциональной полезности или вовсе без оной. Тут-то и могут вскрыться интересные подробности.
В одной крупной электрической компании имелась база данных, собирающая эксплуатационную и прочую информацию за несколько лет от разнообразных датчиков и устройств в распределительной сети национального масштаба. Некоторые параметры отличались очень коротким интервалом замеров - «каждые N секунд». В итоге размер хранилища составляет около 3 терабайт информации за несколько фиксированных лет эксплуатации.
В общем, такой размер не является маленьким и для промышленных СУБД, требуя дополнительных усилий в проектировании, реализации, настройке и поддержке. Но пикантность ситуации состояла в том, что база данных была организована в виде двоичных файлов собственного формата.
Признаюсь, последний раз я видел такой подход в далёком 1994 году, когда мы переводили паспортные столы Санкт-Петербурга с подобных плоских файлов на прогрессивный по тем временам и, что важнее, открытый формат DBF под Clipper и FoxPro для MS-DOS и Novell-серверов. С оговорками перехода от флоппи-нет [115 - От англ. floppy net - жаргонное обозначения псевдосети передачи информации между устройствами с помощью гибких дисков. В современном варианте звучало бы как «флэшка-нет».] на каналы удалённой связи, многие паспортные службы долгое время продолжали в этой системе работать, характерные алфавитно-цифровые экраны в DOS-окошке я наблюдал уже в начале 2000-х годов.
В долговременной памяти всплыли воспоминания случаев необходимости ручного декодирования форматов. К великому счастью, программисты системы не занимались тогда «эволюционной» разработкой, а знали область, в которой работают, и добросовестно поддерживали проектную документацию в актуальном состоянии. Кроме возможности прочитать собственно об устройстве системы, все описания форматов двоичных файлов также были на месте. Возникший было тёмный призрак индустриальной археологии растворился в лучах взошедшего солнца.
Поскольку в нашу задачу входило предпроектное обследование, начались интересные опыты с технологиями новыми. Начали с прототипа конвертера, извлекающего данные из старых форматов и распределяющего их по таблицам промышленной СУБД, в качестве которой выступал SQL Server. Логично было бы написать такой прототип на C++ или другом языке с возможностями прямого доступа к памяти на уровне битов, но ввиду планируемой общей разработки исключительно на C# необходимо было оценить соответствующую программу в ипостаси распаковщика байтов.
Быстро выяснилось, что побитовые операции с типами данных разной длины не являются сильным местом языка и платформы в целом. Как, например, задать ushort или вообще любую константу в двоичном виде? Никак. A ushort в шестнадцатеричном? Тоже никак, константа определяется как int, все остальные преобразования надо делать в небезопасном контексте unchecked(). В итоге код достаточно простого алгоритма пестрел вот такими вставками, которые, на минуточку, суть рекомендуемые практики. Нас настигла расплата за автоматическое управление памятью.

Convert.ToUInt32(«00110000», 2);
unchecked((ushort) 0xC0);

Вторым пунктом была собственно база данных. На логическом уровне структура для тестируемого случая никаких сложностей не представляла: одна узкая длинная таблица, связанная с несколькими короткими справочниками, практически «звезда», но в режиме постоянного добавления пачек новых записей. Трудность представлял собой уровень физический. Втиснуть число-признак, кодируемое тремя битами, в те же три бита на уровне СУБД стандартные средства не позволят. Минимальный размер - байт. Использовать нестандартные битовые поля в принципе можно, но тогда мы лишимся поддержки ссылочной и прочей целостности, возможности использовать SQL для выборок без переупаковки значений в битовые структуры и фактически будем использовать СУБД в качестве продвинутого аналога файлового хранилища с улучшенными функциями администрирования.
Поскольку целью было упрощение работы с пользовательскими запросами, то лишать их доступа к данным посредством прямого и понятного человеку SQL было решительно невозможно. При использовании минимальных по размеру стандартных типов данных прогнозируемый размер базы данных без учёта дополнительных индексов превысил 6 терабайт, то есть минимум удвоился по сравнению с двоичными файлами. Сжатие данных несколько скрасило ситуацию, полученные 4,5 терабайта выглядели уже неплохо. За всё надо платить, в том числе за стандартность доступа и представления данных.
Третьим пунктом была загрузка данных из C#-пpилoжeния в базу данных. Поскольку интенсивность вставки из прибывающих от датчиков текстовых файлов составляла почти 400 тысяч записей каждые 10 минут, то, разумеется, приложение должно было справляться с этой задачей за меньшее время. Оптимальной, как и следовало ожидать, оказалась пакетная загрузка, игнорирующая ограничения целостности РСУБД. Такова обычная цена компромисса.
Что имеем по итогам более чем 10-летнего развития технологий? Появилась возможность стандартизировать хранение и доступ к большому массиву данных, используя вполне обычное серверное оборудование корпоративного класса и 64-разрядную промышленную СУБД. Возникла необходимость переделывать программное обеспечение из-за утраты поддержки среды разработки поставщиком и соответствующих компетенций на рынке труда.
Но я совсем не уверен, что ещё через 10 лет новые подрядчики, вынужденные в очередной раз переписывать систему, найдут документацию в том же полном виде, в котором нашли её мы. Если вообще найдут хоть что-то, кроме кода, остатков презентаций и наших отчётов.

Vitamin

23.10.2014, 07:50

Лодка не плывёт далеко, хотя Бомбаров это не смущает, но она за счёт своей лёгкости меняет курс быстрее Титаника. Но грести приходится всё-таки ручками, на что многие обижаются. Можно конечно прицепить мотор, но уже требуется топливо и теряется совместимость с весельной версией лодки.
А если таки требуется плыть далеко?

Быстро выяснилось, что побитовые операции с типами данных разной длины не являются сильным местом языка и платформы в целом. Как, например, задать ushort или вообще любую константу в двоичном виде? Никак. A ushort в шестнадцатеричном? Тоже никак, константа определяется как int, все остальные преобразования надо делать в небезопасном контексте unchecked().
А нахрена?

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

jerri

23.10.2014, 09:16

Это jerri требовал. Сам для себя он считает возможным делать чего хочет, чего угодно хвалить и чего угодно обсирать. Мне же предписывал появиться на задних лапках, но без короны, и начать всех удивлять крутыми играми на Обероне. Я мож бы и поступил так, но проекты всё долгоиграющие, а поддержки никакой, даже моральной.

Jerri в этом треде не пишет уже давно, а тебе я смотрю без него скучно стало? Зачем призываешь?

Eltaron

23.10.2014, 09:48

\dotnetfx35.exe\wcu\.\.\.\.\.\dotNetFramework\dotN etFX20\
\dotnetfx35.exe\wcu\.\.\.\.\.\dotNetFramework\dotN etFX30\
\dotnetfx35.exe\wcu\.\.\.\.\.\dotNetFramework\dotN etFX35\
\dotnetfx35.exe\wcu\.\.\.\.\.\dotNetFramework\dotN etMSP\
\dotnetfx35.exe\wcu\.\.\.\.\.\dotNetFramework\Tool s\
\dotnetfx35.exe\wcu\.\.\.\.\.\dotNetFramework\dotN etFx35setup.exe

Там инкрементальные улучшения. Основная масса библиотек неизменна со времен 2.0. 3.0 принес WCF, WPF и WWF, все в отдельных либах. 3.5 - LINQ, Linq2Sql, Linq2Xml, это всё тоже отдельные либы. 4.0 - дал Entity Framework, 4.5 - пространство System.Task для асинхронного выполнения. И то, и то - тоже отдельные либы. Плюс постоянно развивается язык, но там хранится обратная совместимость, и 2.0 проект собирается без проблем 4.5 компилятором.

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

Convert.ToUInt32(«00110000», 2);
unchecked((ushort) 0xC0);

Зачем тут unchecked, я не понял. Там действительно постоянные переполнения при работе с короткими числами, но для их обхода достаточно простого приведения типа.

const ushort A = 0x2312;
const ushort B = 0x2014;
ushort C = (ushort)(A + B);

А за первую строку нужно убивать. Отсутствие средств языка не повод плодить потенциальное Runtime exception.
Все разы, когда мне нужна была двоичная константа, я писал так и не парился:

const byte mask = 0x30; // 00110000

Можно ещё более безопасно

[Binary("00110000")]
const byte mask = 0x30;

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

ZXMAK

25.10.2014, 05:59

Зачем тут unchecked, я не понял.

Тот кто писал такой код, просто не знал C# :biggrin:
Конечно, статья полный бред, для указанной работы именно c# более всего подходит, а не c++, но нужно хоть книжку какую почитать по языку, прежде чем начинать писать на нем :biggrin:

PS: переписал код эмуляции Z80, на лямбдах ;) :D скорость должна заметно вырости, занялся переписыванием движка, в старом связанность очень большая и много рудиментов :)

SfS

25.10.2014, 06:48

Позволь простой пример. Сишник пишет:

void fn() {
int *a; a = 1234; *a = 1234; // я выстрелил себе в ногу - ура!
}Это парадигма Си.

Нормальный компиляторы выдают предупреждение, если тип не приведён принудительно.

Кроме того, обычно я ставлю опцию -Werror, которая трактует все предупреждения, как ошибки. И всё. Не прокатит твой пример.

А вообще "об дуру можно и член сломать".. В смысле - что любой инструмент можно и нужно использовать с умом.

s_kosorev

25.10.2014, 12:17

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

Чисто номинально BB позволяет реализовывать такой функционал, но 2 года мучения с поддержкой, меня добили, одних подсистем было 75 штук в каждой не меньше 10 юнитов.

Без отладчика и нормальной среды разработки BB очень не приспособлен к реальной эксплуатации, казалось бы простые ошибки, а на исправления по 2 рабочих дня уходит. Приходиться иногда целый модуль писать для воспроизведения состояния системы в котором возникает ошибка, тогда еще не знал что это называется Unit Test. В общем очень неудобная парадигма в BB, можно сказать она её нет, разработчики приложения пытались реализовать что похожее на инверсию зависимостей, но язык не приспособлен и пользоваться этим было невозможно.

Разработчики которые писали эту систему, отказались от поддержки, сказали что BB морально устарел и специалистов нет, предлагали переписать все на 1С.

В итоге разработал конвертер кода в C# и за полгода перенес все на .net, еще полгода переписывал интерфейсные вещи и движок БД, добавил нормальный Reporting.

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

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

Oleg N. Cher

28.10.2014, 03:02

s_kosorev, спасибо, было интересно. Кстати, даже удивлён узнать о таком использовании BlackBox.

Всё так, не поспоришь. Правда, окружение очень важно, сообщество большое важно и т.д.

Но всё-таки я утверждаю, что C# и .NET хороши именно для типичных задач, где-нить на производстве. Там да, плюсов много.

А по Оберон-технологиям мало специалистов - это конечно так, но хороший спец по C# разберётся в Оберонах. Если понадобится.

Посмотрите, пожалуйста, вот это видео:

Прошивка контроллера Cortex-M3 (LPC1343F) программой на Oberon (https://www.youtube.com/watch?v=zlnj6FCY1tY)

Пара комментариев. Здесь показан самопальный компилятор, сделанный одним человеком - Александром Ширяевым. Это к вопросу создания компилятора Оберона для Z80. Да, это несомненно гораздо легче, чем сделать компилятор Си. Однако где желающие этим заняться? Что-то не замечены.

Дальше. На видео вы можете видеть BlackBox, запущенный в среде Ubuntu. Это нативная линукс-версия, адаптированная из авторской виндовской версии очень небольшим коллективом разработчиков. Просто сами делайте выводы.

Сам BlackBox был разработан швейцарской фирмой Oberon microsystems (http://oberon.ch), насчитывающей человек 15 разработчиков. Фирма, само собой, коммерческая. Правда, уже перешла на дотнеты и забила на BlackBox - есть повод позлорадничать.

Ну и я сам адаптировал транслятор (Оберона-2 в Си) Ofront с Linux для командной строки Windows. Справился за несколько вечеров. Очень грамотно сделан, всё по полочкам. Также я вношу в него доработки с поражающей меня самого лёгкостью.

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

jerri, да вот всё не теряю надежды что ты наконец-то займёшься Обероном. ;)

Andrew771

28.10.2014, 09:25

Однако где желающие этим заняться? Что-то не замечены.
Усеченный Паскаль для ZX я лабаю потихоньку.

Oleg N. Cher

28.10.2014, 23:30

Andrew771, спасибо, мы в курсе.
Правда, Паскаль - не Оберон в двух смыслах. В первом - Оберон более современен и содержит такие средства, которые есть в более поздних языках - Java, C#, и содержит их с самого начала. А в Дельфи они - частью были добавлены по мере его разрастания, да и то не все. Хотя Оберон - язык-ядро, и некоторых средств Паскаля/Дельфи в нём нет (или есть, но не во всех диалектах; впрочем, про диалекты - разговор отдельный).

И когда я искал язык для того чтобы с энтузиазмом им заняться (критерии были: простота, переносимость/портабельность, ясность, прозрачная компиляция в машинный код; потом добавились безопасность и надёжность - чтобы не рисковать жизнью при ежедневном пути на работу) - мой выбор (при любви к Паскаль-синтаксису) оказался не таким уж большим: Модула-2, Оберон или Си. Выбрал я, можно сказать, всё вместе, слегка проигнорировав Модулу-2, ну да ничего. Оберон я рассматриваю как усовершенствованный Паскаль, концептуально более ясный. А транслировать его в Си в общем-то не совсем правильно из-за того, что Си не отражает в полной мере важных возможностей Оберона. Но это было сделано вследствие того, что я себя и свой темп работы знаю - я могу делать проект 10 лет и так его и не закончить. Так что это правда - показывать jerri мне было почти что нечего.

Почему я не влился в твой проект, Andrew771 - да просто потому что у нас разные цели. Мне претит такая большая ограниченность твоего компилятора (ты даже графические процедуры зашил в компилятор, сделав, таким образом, язык-инвалид только для Спека, а даже не для MSX). Плюс закрытые исходники и нежелание делить идеологическое направление развития компилятора с кем-либо ещё. Ну а самая главная причина - это моё нежелание делать компилятор в машкод (я тоже как эти товарищи из предприятия люблю готовые средства для решения своих задач, просто они у меня слегка другие - ну как я могу интересоваться кортексами если я их никогда не видел?). Зато стратегия трансляции в Си окупится при использовании всяческих Raspberry Pi и не-x86 Linux'ов. Потому что заниматься генерацией кода под всё это - сотни человеко-лет работы. А делать, понимаете, хочется всё-таки не игрушку, а рабочий инструмент.

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

Ну а Andrew771 не приходит в проект ZXDev по его собственным причинам. Хотя это почти тот же самый бог, ну просто очень сильно похож. ;)

Oleg N. Cher

10.11.2014, 22:48

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

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

Bolt, ну на самом деле Олег не хочет заниматься генерацией машинного кода сам. Если таких Олегов-единомышленников будет человек десять, то почему бы и нет. XDev ведь по задумке это что? Мультитаргетная и мультиязычная среда разработки. И трансляция в Си - это не диагноз, а только одна из схем трансляции. Тот же Ofront можно рассматривать как бэк-энд (с Си в качестве таргет-платформы) для OP2, на базе которого он построен. Есть также и другие бэк-энды к OP2 (в машинный код для самых различных процессоров) и к расширенному OP2.

Кроме OP2 есть компиляторы Oberon-0 (подмножество Оберона для раскрутки компиляторов) и Oberon-07 в машинный код. Их можно взять в качестве базы для собственного компилятора.

Так что Олег просто отложил задачу генерации машинного кода в долгий ящик, сосредоточившись на кодовой базе, без которой всё равно не обойтись. Могу также добавить, что мультитаргетный компилятор Паскаля мне интересен, но призываю всё же не морочиться с сегментами и оверлеями. Выбором адекватной по размеру адресного пространства платформы для разворачивания компилятора избегается множество проблем. Вместе с тем, не исключаю появление задачи, для которой действительно необходимо втиснуть компилятор в адресное пространство 64 кб, но это жесть. Успехов!

Vitamin, полюбопытствуй: просто статья про ООП, может тебе будет интересно. Автор владеет терминологией и методами ООП в современной реинкарнации. Я же программерствовал десятилетие назад и уже несколько устарел. ;) Хотя меня неприятно удивляет как те приёмы, которые мы когда-то изобретали для облегчения жизни, теперь получили официальные и непонятные английские названия и нас же ими тыкают носом - учат программировать по-новому. :)

Кризис объектно-ориентированного программирования (http://rainman-rocks.livejournal.com/122876.html)

Alex Rider, вероятно, в январе 2015 будет выпущена первая версия XDevLite - как раз та самая IDE, зашитая в одну exe'шку, о которой ты говорил. Экспериментировать с ней можно уже сейчас. Скачиваешь с репозитория архив XDev (https://github.com/Oleg-N-Cher/XDev/zipball/master) (возьми посвежее), открываешь XDev/Bin/Lite.odc и последовательно сверху вниз жмёшь два коммандера (чёрненьких кругляша). В корне сгенерируется файл XDev.exe - это и есть "IDE в одной exe'шке", как ты и просил. В папку с ней также добавь подсистему ZXDev и тестируй. Для пересборки библиотек ещё понадобится утилита Bin/smartlib.exe.

Реалии таковы, что ZXDev сегодня - уже не только среда разработки на Обероне для ZX, но и центр по высокоуровневой разработке для ретро-платформ вообще. Для SDCC вы видели подбор библиотек? Самый большой - как раз в ZXDev. А низкоуровневая разработка меня в первую очередь интересует не как самоцель, но только как фундамент для высокоуровневой.

Господа, анонсирую подсистему MsxDev (http://zx.oberon2.ru/forum/viewtopic.php?f=89&t=210). Прошу прощения, если для вас это не новость. Также прошу помощи с кодом и демонстрашками, как обычно.

Bolt

11.11.2014, 01:59

...призываю всё же не морочиться с сегментами и оверлеями. Выбором адекватной по размеру адресного пространства платформы для разворачивания компилятора избегается множество проблем.Да я с ними особо и не морочусь, это так, была некая идея, которая отложена в ну уж совсем долгий ящик, а запуск на ZX это было где-то рядом с той идеей. А вообще то, что есть, собирается FPC и тестируется под Ubuntu.
Кодогенераторов было 4 "поколения", последняя версия выдавала хоть и очень неоптимальный код, зато для PIC16, PIC18, PIC24, STM8 и x86. Но всё равно это не то что хотелось бы, компилятор получился довольно запутанный, надо его делить на модули с чётким разделением задач.

Oleg N. Cher

11.11.2014, 03:18

Внимательное сопоставление вот чего говорит. Как видим, ZXDev не хотят пользоваться из-за "промежуточной трансляции в Си". Но, кстати, я делаю всё чтобы кодер мог работать на ZXDev без знания языка Си.

А ещё - потому, что опытный асмер фукает, что процедура занимает 10 байт, а могла бы 8. В Оберон-сообществе я вижу другую проблему. Есть система разработки BlackBox Component Builder, и она основана на прямой трансляции в машинный код. Знаете какие недостатки вызывают возмущение? Слабое качество кода (компилятор простой), нет поддержки MMX и других более поздних систем машинных команд, нет генерации 64-битного кода. И это действительно серьёзные проблемы, потому что требуют мощной квалификации и мощного сообщества для их преодоления. О коварные люди! Вам не нравится любой недостаток, даже если в несколько другом ракурсе он является достоинством. ;)

Но из-за "нативного" подхода система BlackBox работает только на x86-Linux. И даже не 64-битный. Но вот когда я смогу собирать его модули своим XDev, тогда это будет серьёзный прорыв.

Bolt, тут есть ещё одна вещь, с которой обязательно сталкивается написатель компилятора. Нужен промежуточный формат объектных файлов, формат для хранения библиотек и т.п. Если взять готовый - могут возникнуть проблемы из-за неподдержки им фич, которые могут понадобиться в компиляторе. Если наваять форматы самому - возникают проблемы из-за несовместимости с другими готовыми популярными форматами и средствами, их поддерживающими. Но как стыковать мультиязыковую систему разработки если не на базе единых форматов? Есть и промежуточное решение - конвертер из "своего" формата в готовый (и обратно). Но тут тоже появляются недостатки... и т.д.

В плане наведения порядка в компиляторе советую статьи Пола Рида (Paul Reed):

(2000) Building Your Own Tools - An Oberon Industrial Case-Study
(2003) An Oberon Linker for an Imperfect World – More Notes on Building Your Own Tools

Есть в торрент раздаче книг и статей по Оберону (на NNM-Club) (http://nnm-club.me/forum/viewtopic.php?p=6256036).

Ещё можно почитать книжку "Построение компиляторов" Никлауса Вирта (есть там же). Мне очень нравится как устроены компиляторы Оберона изнутри. Чёткое деление на промежуточный код, фронт-энд и бэк-энд, есть готовый инструментарий для автоматизированного построения фронт-энда из форм Бэкуса-Наура, сам код очень приятно дорабатывать, вносить фичи и т.д.

Bolt

11.11.2014, 10:00

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

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

Книги я искал когда совсем не понимал с чего начать, а сейчас понимание общих идей уже есть, надо думать над реализацией. Например, как в дереве хранить CASE. Но за названия спасибо, а то везде одно и то же: "Сегодня мы будем писать компилятор. Он будет поддерживать один тип byte, глобальные переменные с именем из одной буквы, числа из одной цифры и 4 арифметических действия. А, ещё процедуры без параметров и локальных переменных. Функции добавите сами." :)

Vitamin

11.11.2014, 10:17

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

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

b2m

11.11.2014, 11:12

Статья интересная, чувствуется интерес автора к вопросу.
Тоже почитал. Автор - типичный теоретик, интересно было почитать его дискуссию с практиком в комментах. :)

Alex Rider

11.11.2014, 11:35

Как видим, ZXDev не хотят пользоваться из-за "промежуточной трансляции в Си". Но, кстати, я делаю всё чтобы кодер мог работать на ZXDev без знания языка Си.
А ещё - потому, что опытный асмер фукает, что процедура занимает 10 байт, а могла бы 8.

Олег, за весь мир не скажу, но конкретно по этому сообществу - в основном тут люди, ностальгирующие детскими увлечениями. Вот было многое на ZX помимо ассемблера и бэйсика - и C, и паскаль, и форт, и лого, и всякие высокоурвневые редакторы... Но вот Оберона не было ну совсем. Не аутентично оно как-то. Это основная причина непопулярности Оберона здесь. Кстати, как и прочих JScript'ов, кросс-паскалей и даже новомодных фишек АТМ'а (его SDK, например). Остальное вторично.

Vitamin

11.11.2014, 11:39

Автор - типичный теоретик
И с чего сделан такой вывод?

Eltaron

11.11.2014, 11:52

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

Vitamin

11.11.2014, 12:18

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

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

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

Eltaron

11.11.2014, 14:01

Пример дашь?
Навскидку

public Base
{
virtual int GetSomething1() = 0;
virtual int GetSomething2() = 0;
virtual int GetSomething3() = 0;
virtual int GetSomething4() = 0;

void DoJob() { print((GetSomething1()+GetSomething2()+GetSomethin g3()+GetSomething4()) * 57.2418); }
}

public Child : Base
{
int GetSomething1() { return 90; }
int GetSomething2() { return 5; }
int GetSomething3() { return 17; }
int GetSomething4() { return 9; }
}

переписывается в идеологии статьи как

typedef int (*get_something)();

public Base
{
void DoJob(get_something param1, get_something param2, get_something param3, get_something param4)
{
print((param1() + param2() + param3() + param4()) * 57.2418);
}
}

public Child
{
Base* base;
Child(Base* base) { this.base = base; }

void DoJob() { base->DoJob(GetSomething1, GetSomething2, GetSomething3, GetSomething4) };
int GetSomething1() { return 90; }
int GetSomething2() { return 5; }
int GetSomething3() { return 17; }
int GetSomething4() { return 9; }
}

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

Vitamin

11.11.2014, 14:05

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

Andrew771

11.11.2014, 15:35

Олег, за весь мир не скажу, но конкретно по этому сообществу - в основном тут люди, ностальгирующие детскими увлечениями. Вот было многое на ZX помимо ассемблера и бэйсика - и C, и паскаль, и форт, и лого, и всякие высокоурвневые редакторы... Но вот Оберона не было ну совсем. Не аутентично оно как-то. Это основная причина непопулярности Оберона здесь. Кстати, как и прочих JScript'ов, кросс-паскалей и даже новомодных фишек АТМ'а (его SDK, например). Остальное вторично.
Неа. Hisoft Паскаль и ассемблер (Gens) фиговаты, не удобны. Особенно бесит нумерация строк. На их Паскале серьезного ничего не напишешь. Поэтому пишем свои компиляторы.

Alex Rider

11.11.2014, 16:32

Hisoft Паскаль и ассемблер (Gens) фиговаты, не удобны.
Не знаю как обстоит дело с Паскалем для Z80, а у GENS'а есть достаточно удобных последователей. Да и в любом случае, компилятор Паскаля для Z80 я понимаю, сам даже баловался. А вот компилятор C# для Z80 не пойму.
PS Вернее, не так. Компилятор с C# для Z80 не поймут именно тут.

b2m

11.11.2014, 16:40

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

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

Vitamin

11.11.2014, 16:49

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

Ну конечно. Лучше лишнего написать, чем лишний раз подумать.

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

Q-Master

11.11.2014, 20:06

Аффтар всего лишь рассуждает, можно ли полностью отказаться от наследования имплементации в пользу агрегирования (имхо, можно и даже нужно! И да, читай замечания).

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

b2m

11.11.2014, 21:06

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

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

И пока не осознаешь этого, так и будешь писать "брутальный *****код, представляющий собой кровавый замес из процедурного C, недообъектного и недотипизированного C++" (С)
В том, что программы с ошибками пишутся, чаще всего виноваты люди, а не парадигмы.

Vitamin

11.11.2014, 21:29

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

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

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

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

b2m

12.11.2014, 11:13

Согласен.

Oleg N. Cher

13.11.2014, 03:49

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

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

Один из компиляторов поразил меня невозможностью получения указателя на элемент массива, так и сказал: обнаружена "[" вместо ";". Это я к тому, какие интересные бывают реализации "в лоб". FPC тоже примечателен в плане реализации, его исходники открыл... и закрыл. IF THEN ELSE IF на сотни строк, в которые вложены другие IF THEN ELSE IF. В итоге куда там прикручивать кодогенератор так и понял.Кстати, можно ещё посмотреть Amsterdam Compiler Kit (ACK) (http://ru.wikipedia.org/wiki/Amsterdam_Compiler_Kit) - мультиязычную и мультиплатформенную среду разработки.

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

Я не против промежуточной трансляции в Си вообще, но, например, для микроконтроллеров PIC16/PIC18 в таком случае всё упирается в те же уже имеющиеся и не совсем совместимые между собой компиляторы. Ещё и платные. Зачем тогда? Как временное решение для генерации хоть какого-то кода?Ну да. Иногда результат нужен быстро. Впрочем, даже к платному компилятору нужна заточка Си-генерации до его фич, в зависимости от поддерживаемого стандарта - ISO или там ANSI. ( можно посмотреть PICL: язык программирования для микроконтроллеров PIC (http://www.inf.ethz.ch/personal/wirth/Articles/Miscellaneous/) - предтеча Оберона ).

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#, а в том, чтобы не переписывать завтра систему заново на другом языке. А подтянуть Оберон к своей системе. Под новый проц или новую ОС. Да мало ли...

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

Дмитрий Викторович Дагаев (http://www.youtube.com/watch?v=HeaeQTcQZZQ). Доклад №1: Коммуникационное ПО на языке Оберон для автоматической системы сбора данных на втором энергоблоке Ростовской АЭС.

Евгений Анурин & Павел Маркин (http://www.youtube.com/watch?v=XcvatQoAigk). Доклад №3: Автоматизация медицинской лаборатории

Иван Александрович Кузьмицкий (https://www.youtube.com/watch?v=S5eBCKlnbsM). Доклад №6: SDL2.0 как дополнительный слой для портирования Блэкбокса

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

Vitamin

13.11.2014, 10:27

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

denpopov

13.11.2014, 12:22

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

Q-Master

13.11.2014, 22:19

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

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

Vitamin

13.11.2014, 22:57

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

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

Oleg N. Cher

14.11.2014, 02:46

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

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

jerri

14.11.2014, 09:12

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

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

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

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

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

Oleg N. Cher

14.11.2014, 20:09

а свои в 512 писал?
скажу по секрету - это сложноПисал TinyTetris в 2 кб. Представление имею.

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

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

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

Q-Master

14.11.2014, 20:13

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

При чем тут перевызов? И да, в данном контектсе это будет ф-ция делегат.

Oleg N. Cher

14.11.2014, 21:53

Ещё добавлю. Хорошо заниматься мультиплатформенностью на платформе, которая тянет .NET, JVM и DOSBox, с запущенной внутри Windows 95. А я целенаправленно решаю более трудную задачу - специально взял такие специфические платформы, которые требуют очень особого подхода при разработке, такие как Java micro edition, DOS с CGA-графикой, Спектрум и MSX. На них эмулятор Windows не запустишь, а значит подход к разработке должен быть нетривиальным. И конечно у моего решения есть недостатки. Но совсем не те, которые вы с denpopov'ым даже не трудитесь вербализовать. Вы эти проблемы мультиплатформенности полностью игнорируете и никаких решений вообще не предлагаете, ибо сильно зациклены на проце Z80 и наиболее качественном для него ручном кодировании. Ну занимайтесь. Или коробки спичечные коллекционируйте, это ваше дело. Но почему столько бешенства и слюны в мою сторону?

И XDev - не просто мощная среда. Это уникальная среда, вообще не имеющая аналогов, ибо объединяющая (или пытающаяся объединить) такие таргеты, которые никто до неё не пробовал объединить. А старинные они или нет - это неважно, в том смысле что если таргеты такие разномастные, то туда можно припилить вообще что угодно. И это так.

Так что наезды в стиле "мне эта нинада" меня никак не колышут. А за наезды в стиле "никому это нинада" буду тыкать носом в г-но, и, считаю, заслуженно. Потому что каждый вправе не только коллекционировать спичечные коробки, но и рассказывать об этом другим. И пусть, раз вам не нравится обсуждать в этой ветке вопросы ZXDev, её целью будет именно это тыкание, раз уж нет другой, более достойной цели.

Vitamin

14.11.2014, 22:16

При чем тут перевызов? И да, в данном контектсе это будет ф-ция делегат.
Потому что основная задача паттерна "делегат" - именно перевызов. Равно как и прочих подобных паттернов (прокси, мост, фасад - первое что на ум приходит). И почему это плохо?

Q-Master

16.11.2014, 19:21

Потому что основная задача паттерна "делегат" - именно перевызов. Равно как и прочих подобных паттернов (прокси, мост, фасад - первое что на ум приходит). И почему это плохо?

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

Vitamin

16.11.2014, 20:13

Где конкретно я написал про плохо?
Тут

Закрыть обратно нафиг.

---------- Post added at 20:13 ---------- Previous post was at 20:11 ----------

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

Oleg N. Cher

30.11.2014, 15:13

Прогресс разработки игры Dark Woods (http://zx.oberon2.ru/forum/viewtopic.php?f=5&p=1332#p1332)
Библиотека Wham: двухголосная музыка с шумовыми эффектами на бипер (http://zx.oberon2.ru/forum/viewtopic.php?f=10&t=226)
Буферизованный опрос клавиатуры (http://zx.oberon2.ru/forum/viewtopic.php?f=10&t=221)
Опрос управления от клавиатуры и джойстиков (QAOPSpace, Sinclair 1, 2 и Kempston Joystick) (http://zx.oberon2.ru/forum/viewtopic.php?f=10&t=216)
ZXDev + кириллица (http://zx.oberon2.ru/forum/viewtopic.php?f=10&t=194)
На ZXDev как на ZX-Basic + NewSupercode: игра «Звёздная война» (http://zx.oberon2.ru/forum/viewtopic.php?f=10&t=204)
Теоретическое обоснование подсистемы XDev/Pdp11Dev (http://zx.oberon2.ru/forum/viewtopic.php?f=51&t=220)
Реструктуризация подсистем WinDev и ZXDev (http://zx.oberon2.ru/forum/viewtopic.php?f=8&t=84#p1355)
Как подключить ресурсы (спрайты, шрифты, музыку). Константные массивы (http://zx.oberon2.ru/forum/viewtopic.php?f=8&t=213)

Oleg N. Cher

16.12.2014, 05:50

Вот пример кода, к которому будет трудно придраться даже самому искушённому кодеру. Проделана конечно чёртова работа, но, раз сделанная, остаётся таковой. Это пример, неважно что маленький, того, как я представляю себе кодогенерацию ZXDev с ЯВУ, доступную кодеру на ZX-бейсике, даже не знающему Си и асма. Если сделать на это ставку и начать развивать, наполнять кодовую базу, то это будет неизмеримо круче, чем есть сейчас. Мне несколько обидно, что кто-то вместо того чтобы развивать это направление, упивается процессом кодинга на асме, который не претерпел особых изменений с 1985 года. И которому развиваться дальше в общем-то некуда.

MODULE Durak; (** non-portable *)
IMPORT B := Basic;

(* ================================================== ======================== *)

PROCEDURE Main; (* Prepare title, init game data. *)
VAR
radius: INTEGER;
BEGIN (*$MAIN*)
B.Init;

(* Prepare screen & title, set up colors, write "WAIT...": *)
(* ------------------------------------------------------- *)
B.OVER(B.Off); B.FLASH(B.Off); B.INVERSE(B.Off); B.BRIGHT(B.Off);
B.PAPER(B.Black); B.INK(B.LightGray); B.BORDER(B.Black); B.CLS;
B.AT(21, 3); B.PRSTR("WAIT...");

(* Draw invisible circles & prepare drawing logotype "M": *)
(* ------------------------------------------------------ *)
B.INVERSE(B.Off); B.INK(B.Blue);
radius := 8;
REPEAT B.CIRCLE(121, 85, radius); INC(radius, 8) UNTIL radius = 72;
B.POKE(23112, B.Blue); (* Fix attrib for accuracy. *)
B.Quit;
END Main;

END Durak.
; ---------------------------------
; Function Durak_Main
; ---------------------------------
_Durak_Main:
;Durak.c:16: Basic_Init();
DI
RES 4, 1(IY)
;Durak.c:17: Basic_OVER(0);
ld c,#0
call _Basic_OVER_ROM_fastcall
;Durak.c:18: Basic_FLASH(0);
ld c,#0
call _Basic_FLASH_fastcall
;Durak.c:19: Basic_INVERSE(0);
ld c,#0
call _Basic_INVERSE_ROM_fastcall
;Durak.c:20: Basic_BRIGHT(0);
ld c,#0
call _Basic_BRIGHT_fastcall
;Durak.c:21: Basic_PAPER(0);
ld c,#0
call _Basic_PAPER_fastcall
;Durak.c:22: Basic_INK(7);
ld c,#7
call _Basic_INK_fastcall
;Durak.c:23: Basic_BORDER(0);
xor a
call 0x229B
;Durak.c:24: Basic_CLS();
call _Basic_CLS_ZX
;Durak.c:25: Basic_AT(21, 3);
call _Basic_AT_ROM_fastcall
.db 21,3
;Durak.c:26: Basic_PRSTR((CHAR*)"WAIT...", (LONGINT)8);
call _Basic_PRSTR_C_ROM_fastcall
.ascii "WAIT..."
.db 0x00
;Durak.c:27: Basic_INVERSE(0);
ld c,#0
call _Basic_INVERSE_ROM_fastcall
;Durak.c:28: Basic_INK(1);
ld c,#1
call _Basic_INK_fastcall
;Durak.c:30: do {
ld de,#0x0008
00104$:
;Durak.c:31: Basic_CIRCLE(121, 85, radius);
push de
push de
ld hl,#0x5579
push hl
call _Basic_CIRCLE_DI
pop af
pop af
pop de
;Durak.c:32: radius += 8;
ld hl,#0x0008
add hl,de
ex de,hl
;Durak.c:33: } while (!(radius == 72));
ld a,e
sub a,#0x48
jr NZ,00104$
or a,d
jr NZ,00104$
;Durak.c:34: Basic_POKE(23112, 1);
ld hl,#0x5A48
ld (hl),#0x01
;Durak.c:35: Basic_Quit();
LD HL, #0x2758
EXX
LD IY, #0x5C3A
EI
retP.S. Да знаю что всё равно придерётесь, ну и фиг с вами. ;-)

P.P.S. Видели исходники Exolon'a? Не переписать ли Exolon на Oberon? ;-)

Reobne

16.12.2014, 07:39

1. Кодер ZX-basic-а не знает что такое "PROCEDURE","VAR","Main","INTEGER","BEGIN ","END","REPEAT","UNTIL","IMPORT","MODULE"
И что такое точка в выражениях вида "B.Init"
Поэтому надо честно говорить, что придется пролистать книжку про введение в оберон или объект паскаль, либо придётся задавать определённое количество "глупых" вопросов на форумах.
Если он знает Си, то число глупых вопросов сократится на 40%.
Если знает Паскаль или Дельфи, то на 80%, а об остальном можно будет догадаться самому. Но и догадываться это тоже интеллектуальный труд.
2. Неизвестно, есть ещё куда развиваться кодингу на асме (как науке) или нет. Возможно есть пути, которые не видны. Но я почти уверен, что понимание асма конкретным человеком, полезно развивать.
3. REPEAT UNTIL лучше не писать в одну строчку, тогда знающему Си будет проще догадаться, что эти слова - части одной структуры цикла.

REPEAT
B.CIRCLE(121, 85, radius);
INC(radius, 8)
UNTIL radius = 72;

---------- Post added at 11:39 ---------- Previous post was at 11:35 ----------

4. И как ZX-basic-кодеру догадаться, что верхний "код" это то исходник на обероне, а нижний "код" это что получается на асме после компиляции. Блоки кодов лучше подписывать.

Oleg N. Cher

16.12.2014, 08:24

1. Кодер ZX-basic-а не знает что такое "PROCEDURE","VAR","Main","INTEGER","BEGIN ","END","REPEAT","UNTIL","IMPORT","MODULE"Мне сложно представить кодера на ZX-бейсике, который никогда не видел Hisoft Pascal'я или структурных версий бейсика типа BetaBasic и MegaBasic. И потом, кодер - он ведь кодер, а не блондинка.

Поэтому надо честно говорить, что придется пролистать книжку про введение в оберон или объект паскаль, либо придётся задавать определённое количество "глупых" вопросов на форумах.А почему тебя это так напрягает?

Мне самому пришлось очень вдумчиво изучать низкоуровневый кодинг, а после него - не менее вдумчиво компонентный подход в Дельфи. Хотя теперь я не считаю это сложным. Но полезным считаю. Что предлагаю я? Изучить сбалансированный и компактный модульный язык, квинтэссенцию программных абстракций, уточнённых временем. Углубить знания в области написания батников (принцип пригодится для продвинутого использования любой ОС), присмотреться к Си. Многие здесь на форуме слышали что Си это круто, имеют смутное представление о Си и C++, но верят. И они же слышали, что Оберон это отстой. И тоже верят. А когда начинаешь говорить про достоинства Оберон-парадигмы - не верят.

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

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

3. REPEAT UNTIL лучше не писать в одну строчку, тогда знающему Си будет проще догадаться, что эти слова - части одной структуры цикла.Опять отсылаю к HisoftPascal, Beta- и MegaBasic.

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

4. И как ZX-basic-кодеру догадаться, что верхний "код" это то исходник на обероне, а нижний "код" это что получается на асме после компиляции. Блоки кодов лучше подписывать.Я думаю, кодеры догадаются. Не блондинки.

Reobne

16.12.2014, 09:23

Мне сложно представить кодера на ZX-бейсике, который никогда не видел Hisoft Pascal'я или структурных версий бейсика типа BetaBasic и MegaBasic. И потом, кодер - он ведь кодер, а не блондинка.
Но ведь ты писал ранее:

... доступную кодеру на ZX-бейсике, даже не знающему Си и асма.
Так к какой аудитории твой посыл? Не знающий Си и асма, но... знающий структурные версии бейсика и/или паскаль. Это уже другой уровень!

Oleg N. Cher

16.12.2014, 15:31

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

jerri

16.12.2014, 19:32

Reobne, теперь ты меня понимаешь? :)

Oleg N. Cher

16.12.2014, 23:13

SfS

17.12.2014, 12:36

Господа, можно ли средствами сишного препроцессора выкусить из строки кавычки? Т.е. превратить "str" в str

Это позволит использовать модуль Asm, разработанный Reobne для SDCC, также и с другими сишными компиляторами.

Насколько я знаю - нельзя.
Если хочется чтобы для С и АСМ был один заголовочник, то проще делать преобразование sed-ом. У меня в исходниках так и сделано было. в соседней теме.

Oleg N. Cher

17.12.2014, 13:00

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

Oleg N. Cher

18.12.2014, 01:53

А есть книга про программирование на обероне для ZX-а? Или большая статья, чтоб человек, совсем не знающий оберона мог разобраться и начать кодить?Kakos_nonos, вот. Не совсем то, что ты имел ввиду, но максимально приближённое к нему:

Подборочка документов для быстрого старта в Оберон-технологии (http://zx.oberon2.ru/forum/viewtopic.php?f=25&t=107)
Где найти самоучитель? (http://zx.oberon2.ru/forum/viewtopic.php?f=24&t=153#p822)

Также см.

http://zx.oberon2.ru/lib.htm

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

Тажмамат уулу Кубанычбек. Что такое программирование. Кто хочет стать программистом, может начать с этой книги (http://progbookn1.narod.ru)
Eric W. Nikitin. Into the realms of Oberon (очень хорошая книга для начинающих; есть в торрент-раздаче (http://zx.oberon2.ru/forum/viewtopic.php?f=24&t=180))

По специфике «Oberon + ZX» материалов нет, только форум (http://zx.oberon2.ru/forum/viewforum.php?f=10).

ZXMAK

21.12.2014, 04:59

А можно в zxdev добавить язык c# или хотябы си? :)

Oleg N. Cher

21.12.2014, 08:33

Всё можно сделать, трудность в написании транслятора C# в Си (или в машкод Z80).

Поддержка языка Си в ZXDev есть.

Oleg N. Cher

26.12.2014, 14:48

Andrew771, пока твой кросс-Паскаль не достигнет хотя бы приблизительно вот такого качества кода - использовать его для практической разработки смысла не имеет, разве только чтобы потешить своё чувство "уря, Паскаль для ZX!". Впрочем, твоя фраза "а то уже пару людей попросило в личке" говорит о том, что этой паре людей гораздо важнее потешить данное чувство, чем получить хороший инструмент для разработки в лице среды ZXDev, язык которой хотя и слегка отличается от Паскаля, но несомненно в лучшую сторону.

Alex Rider

26.12.2014, 16:29

Andrew771, пока твой кросс-Паскаль не достигнет хотя бы приблизительно вот такого качества кода - использовать его для практической разработки смысла не имеет, разве только чтобы потешить своё чувство "уря, Паскаль для ZX!".
Олег, зачем ты человеку мотивацию портишь? Думаешь, на XDev переберется? Тебе приятно слышать "вот когда на твоем Обероне будут писать миллиарды спектрумистов..."? Один негатив и компаративная фаллометрия. Детсад.

Andrew771

26.12.2014, 16:57

Andrew771, пока твой кросс-Паскаль не достигнет хотя бы приблизительно вот такого качества кода - использовать его для практической разработки смысла не имеет, разве только чтобы потешить своё чувство "уря, Паскаль для ZX!".
это я знаю. Сам ругался на z88dk из-за этого. Он хорош, но выдает вообще неоптимизированный код. Я уже у себя запланировал оптимизацию по некоторым распространенным вещам.
Ясен перец, демо на Паскале/Обероне не напишешь, он только для написания игр и программ.

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

---------- Post added at 16:57 ---------- Previous post was at 16:47 ----------

Олег, зачем ты человеку мотивацию портишь? Думаешь, на XDev переберется? Тебе приятно слышать "вот когда на твоем Обероне будут писать миллиарды спектрумистов..."? Один негатив и компаративная фаллометрия. Детсад.
кстати, будете смеяться, но вся эта дискуссия последних дней раззадорила меня на продолжение компилятора в новогодние каникулы, хотя я планировал заняться второй версией своей игры Euphoria 2D (там осталось доработок на несколько дней буквально, бОльшую часть уже сделал в течение года урывками).

Oleg N. Cher

27.12.2014, 07:58

Олег, зачем ты человеку мотивацию портишь? Думаешь, на XDev переберется? Тебе приятно слышать "вот когда на твоем Обероне будут писать миллиарды спектрумистов..."? Один негатив и компаративная фаллометрия. Детсад.А я просто на наглядном примере показываю вам на ваших же реакциях что выбор языка для разработки имеет все признаки религиозного культа. Здесь и свои заповеди, и свои пророки, и своя библия. И вера. Самое важное. Просто вера в то, что это язык [самый лучший, самый системный, самый подходящий для оптимизации и т.д.]. И твои реакции ничем не отличаются, Алекс. Я подчёркиваю: Оберон отличается от Паскаля незначительно. Но посмотри сколькие даже здесь тянут ручонку за Паскаль, напрочь игнорируя ZXDev и портя мне мотивацию. :v2_dizzy_otvyan:

Alex Rider

27.12.2014, 20:36

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

denpopov

28.12.2014, 05:30

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

учись у рупора - этим ты воспитаешь ненависть к оберону и тебя тихо будут ненавидеть.

Bolt

28.12.2014, 23:07

Andrew771, пока твой кросс-Паскаль не достигнет хотя бы приблизительно вот такого качества кода - использовать его для практической разработки смысла не имеет
Зато имеет смысл заниматься разработкой компилятора.

Oleg N. Cher

29.12.2014, 18:37

Алекс, а я ответил тебе на твои вопросы по Оберону в позитивном ключе до того как увидел твои соболезнования по поводу негатива в сторону кросс-паскаля. Я не против кросс-паскаля. Я желаю успехов этому проекту, но просто ищу ответ отчего более совершенный инструмент ZXDev, предлагающий уникальные возможности, отвергают в пользу менее совершенного и менее готового кросс-паскаля. Кроме того помните что написал Торвальдс Таненбауму по поводу Minix'а? "Дай возможность дорабатывать Minix другим людям под удобной лицензией, и половина моих претензий к нему отпадёт". А здесь тянут ручку не только за менее удачный инструмент, но ещё и за закрытый. Сам же Андрей хоть и вежливо выслушает вас, но сделает всё-равно по-своему. И что-то мне подсказывает, что и исходники не откроет. Так что ответ на мой вопрос "почему?" не лежит в области IT, но в психологии - рефлексы, реакции, подражание и т.д.

попову. предпочитаю ненависть равнодушию. его я ненавижу и в себе, и в других.

denpopov

29.12.2014, 18:40

попову. предпочитаю ненависть равнодушию. его я ненавижу и в себе, и в других.
ССЗБ значит.

Oleg N. Cher

29.12.2014, 18:48

Уже столько негатива как вылили здесь на меня - ещё поискать. Всю тему загадили разговорами про что угодно. Алекс его просто не замечает. А тут, понимаешь, заело. Хотя вот же - все шансы, что кросс-Паскаль постигнет та же участь, что первый сишный компилер vinxru для i8080. Вы такой инструмент хотите? Наслаждайтесь.

Андрею предлагаю сделать две вещи для интереса. Не меняя ни единой строчки кода переименовать проект в кросс-Оберон и дать пару постов о достоинствах Оберона и курсе на него. И он огребёт все плюшки, которые огрёб я. И недоумение "зачем Оберон для Спека?" и всё прочее. Понятно, что Андрей не сделает такого. Он не будет отступать от линии Паскаля даже в сторону убирания лишних begin'ов. А я бунтарь. Мне не нравится сложившаяся ситуация в IT и все те мытарства, через которые приходится проходить программисту чтобы удержаться в струе. И я нашёл своё решение. Только наверно зря предлагаю его здесь, очень уж народ специфический. С кем было бы интересно поговорить - те молчат. А те, кому бы в жизни и руки не подал, влезают в разговор сходу. Грустно.

goodboy

29.12.2014, 18:58

Олег, согласись что труды Андрея на спеке видны, а с твоей стороны только теоретические рассуждения.

Oleg N. Cher

29.12.2014, 19:00

Я свои труды на Спеке не прячу, и все выложил на WoS'е как смог. Если их кто-то не видел - я не виноват. Но речь сейчас не об играх/демках, а о средствах разработки.

goodboy

29.12.2014, 19:05

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

Oleg N. Cher

29.12.2014, 19:12

Ну и что же. Предлагаете сейчас мне писать на чистом асме тогда? А если я не хочу? :) Это интерес такой - ЯВУ на Спеке. А интерес к асму в чистом виде падает. Новая генерация разработчиков не знает ни асма, ни Спека. Скоро новых игр для Спека на асме не будет. Скоро их вообще не будет новых для Спека. И тогда ваш интерес окажется неинтересным, а мой всё ещё интересным. Я тогда буду припиливать XDev к новой платформе, оставляя на плаву его дух.

denpopov

29.12.2014, 19:15

А интерес к асму в чистом виде падает.
Ну почему отпадает и у кого?

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

Так всё плохо, да?
http://img0.joyreactor.cc/pics/post/ванга-мемгенератор-59018.jpeg

Oleg N. Cher

29.12.2014, 19:19

С нового года у меня будет гораздо меньше времени на ZXDev. В информационной поддержке не отказываю - обращайтесь. Но бывать здесь регулярно не обещаю.

Alex Rider

29.12.2014, 21:18

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

Sayman

30.12.2014, 12:24

асм штука интересная. в зависимости от умений и компилятора можно извратиться очень и очень, вплоть до ООП:

Title Ball ~PSW SOFT~

; This is a demo part for the Profi Vision.
; Movable visible object - Ball...

maclib maclib.inc ; Hу это пpосто макpо библиотека...
include OBJECTS.INC ; Здесь макpики и опpеделения имен
; связанных с описанием и выделением
; стандаpтных объектов.
include EVENTS.INC ; Опpеделения имен и масок событий
include VIEWS.INC ; Опpеделения флагов и полей видимых
; элементов

cmEraseAllBalls equ 1251 ; Код события-команды на котоpое pеагиpуют
; все Ball и соотв. уничтожают себя...

DeltaX equ viSkip
DeltaY equ viSkip+1
TimeXY equ viSkip+2
SpeedXY equ viSkip+3
Char equ viSkip+4
BallSkip equ viSkip+5

Object tBall, tView##, BallSkip

Constructor Ball.Init
VirtualMethods <,Ball.Draw,Ball.HandleEvent,,,,,,,,,,,,>

EndObject
и т.д.

компилятор - самый обычный, древнющий Microsoft M80.

Eltaron

30.12.2014, 12:33

так статистика показывает что игры скомпиленные с языка более высокого уровня гораздо ущербнее написанных на чистом асме.
Статистика за какой год? В 2014 назови игру уровнем круче Ninjajar?

Andrew771

30.12.2014, 13:49

Я уже писал причину - Оберон лучше Паскаля, но Паскаль был первым, и намного более распространен среди простых смертных. Аналогия со звуковыми форматами ogg и mp3. Аналогия с Windows и Linux.

goodboy

30.12.2014, 14:08

Статистика за какой год? В 2014 назови игру уровнем круче Ninjajar?
да тот-же MetalMan.
что крутого в NinjaJar ?
из-за скомпиленного (раздутого) кода на данные для спрайтов/карты места впритык.

Eltaron

30.12.2014, 17:28

что крутого в NinjaJar ?
Сюжет и интересность же. На платформе 30-летней давности всё остальное вообще не нужно, кому нужен графон, те купят себе иксбокс.

goodboy

30.12.2014, 17:33

Сюжет и интересность же.
ты наверно в MetalMan и-не-играл толком,там-же не-только мочилово.
причём каждый этап спокойно влезает в 48k,
а в NinjaJar только ~20 комнат и пара/тройка врагов.

Eltaron

30.12.2014, 17:39

ты наверно в MetalMan и-не-играл толком,там-же не-только мочилово.
причём каждый этап спокойно влезает в 48k,
а в NinjaJar только ~20 комнат и пара/тройка врагов.
Окей, попробую.

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

Oleg N. Cher

01.02.2015, 02:05

• Релиз первой версии XDevLite + ZXDev (http://zx.oberon2.ru/forum/viewtopic.php?f=8&t=242).

Oleg N. Cher

02.02.2015, 03:50

Вот ещё ссылочка про нишу Оберона в современном мире айти.

• Оберон-парадигма (http://forum.oberoncore.ru/viewtopic.php?f=6&t=5267)

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

Oleg N. Cher

26.07.2015, 17:37

В Info Guide #11 (http://alonecoder.nedopc.com/zx/books/IG11.ZIP) вышла моя статья «Тонкости при разработке на Обероне в среде ZXDev» (в разделе SYS -> ZXDev).

По разделу SYS журнала констатирую повышение интереса к разработке на ЯВУ (рассматриваются IAR C Compiler, ZX like Pascal, Oberon/ZXDev, Boriel's ZX-Basic Compiler).

Выражаю Saferoll'у благодарность за вычитку статьи.

P.S. В архиве с журналом есть пометка «don't distribute!», но поскольку ссылка уже засветилась (http://zx-pk.ru/showpost.php?p=815815&postcount=15), нахожу возможным опубликовать её и здесь. Статью отдельно от журнала можно будет выложить (с разрешения редакции) позже.

Oleg N. Cher

27.07.2015, 09:10

ZX-клип на Обероне (http://zx.oberon2.ru/forum/viewtopic.php?f=10&t=250), может быть интересен начинающим оберонщикам как пример прикладной программы.

Screw

22.09.2015, 03:07

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

Итак:
1) оберон мощный
2) проекту идет 4ый год
3) на обероне можно писать прекрасные игры, особенно кроссплатформенные.

Покажите мне их. Покажите полезный софт. Пролистав 10 последних страниц я увидел только какой-то маразм с очисткой экрана и рисованием кружочка.

Oleg N. Cher

24.09.2015, 02:14

CodeMaster

24.09.2015, 06:55

А вы покажите мне толпы заинтересованных энтузиастов,
Проект развивается силами 1,5 человек нерегулярно

Подытожив сказанное и 4 года, можно сказать, что это очередной проект just for fun (как изначально лично мне и виделось), что совсем не плохо. Просто, надо это осознать и недомагать Олега результатами.

Screw

24.09.2015, 09:07

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

Проект развивается силами 1,5 человек нерегулярно и несистематически как хобби (моё). Это понятно? Если нет, то увы, я пас.

Феерическая чушь. Если инструмент действительно хороший - он будет использоваться.

1,5 человека, кстати, вместо того чтобы строчить простыни на форум, могли бы сделать набор убедительных samples, как это принято к подобного рода продуктам. Не хрень, типа кружочка, а богатые граф.иллюстрации И полноценную игру, показывающие всю МОЩЬ платформы. Кто, как не автор способен полностью раскрыть сильные стороны технологии ? И скептиков бы умыли, и энтузиастов вдохновили, снабдив точкой старта.

---------- Post added at 09:07 ---------- Previous post was at 09:05 ----------

Подытожив сказанное и 4 года, можно сказать, что это очередной проект just for fun (как изначально лично мне и виделось), что совсем не плохо. Просто, надо это осознать и недомагать Олега результатами.

Я бы более цинично подытожил...

Oleg N. Cher

24.09.2015, 13:09

Screw, я конечно понимаю что в этом сообществе считается хорошим тоном писать пачками игры и демки, показывающие что-то новое. Но эта ветка и сам ZXDev появились не потому, что я принимаю эти правила игры. Я НЕ ИГРОДЕЛ И НЕ ДЕМОМЕЙЕР. Я люблю рисовать кружочки.

ZXDev популяризую как могу. Недавно статью написал. Открыт для общения с юзерами. И т.д. Про популярность инструмента можно говорить тоже много. Вот например. Есть z88dk и более качественный во всех смыслах SDCC. У вас есть разумное объяснение почему на первом разработано на порядки больше игр?

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

s_kosorev

24.09.2015, 14:06

Мне кажется если бы встроить в BlackBox какой нить нормальны редактор хотя бы с простейшим IntelliSense, ну или просто влоб подсказка локальных имен и имен из подключенных модулей, среда намного больше народу привлечет. Редакторов для встраивания сейчас хватает, достаточно в процесс BlackBox вставить Chromium и открыты дороги во все стороны.

Либо как вариант, сделать подсветку синтаксиса, поддержку проектов для какого то из нормальных редакторов (sublime text, atom.io, vs code) и прикрутить из этих редакторов сборку проектов при помощи BlackBox из командной строки.

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

---------- Post added at 14:06 ---------- Previous post was at 14:03 ----------

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

jerri

24.09.2015, 14:52

Oleg N. Cher, ты когда болдердаш допишешь?
он же почти готов.

Oleg N. Cher

24.09.2015, 16:51

jerri, когда-нить допишу. ;) Но он вряд ли вызовет ажиотаж у людей типа Screw’а. Опять же, я не ставлю цели кого-то переплюнуть и всех поразить невиданной игрой. С какой стати? С тем же успехом я могу спросить: ты когда допишешь все проекты, которые задумывал? А у Screw’а с огромным негодованием спрашиваю: я всю жизнь мечтал о порте игры Commander Keen для спека. Вы почему её до сих пор не сделали? ХАЧЮЮЮЮЮ!!! ;)

Мне кажется если бы встроить в BlackBox какой нить нормальны редактор хотя бы с простейшим IntelliSense, ну или просто влоб подсказка локальных имен и имен из подключенных модулей, среда намного больше народу привлечет.Знаете, а я в этом не уверен. BlackBox'ом пользоваться для редактирования вовсе не обязательно, я раньше использовал Syn Text Editor, и нормально.

Сложность реализации данной фичи для меня неподъёмно высока. Поможете? ;)

Либо как вариант, сделать подсветку синтаксиса,Уже давно сделана (http://zx.oberon2.ru/forum/viewtopic.php?f=34&t=95#p257).

поддержку проектов для какого то из нормальных редакторов (sublime text, atom.io, vs code) и прикрутить из этих редакторов сборку проектов при помощи BlackBox из командной строки.Прикрутите. :) Slenkar вот разрабатывал свой рогалик под Linux'ом и не использовал BlackBox вообще. Чем меня немало удивил. Энтузиазмом. А не "всё не так, хачю игр красивых давай!"

человек которые не знаком с библиотекой, нажал ctrl + пробел, ему вывалился список функций, прям по месту написания, а не лезть в описания деклараций модулей, копаться по подсистемами итд.Сделайте, если угодно. Сердце ZXDev - это Ofront, SDCC и библиотеки. Всё, что остальное - то антураж и от лукавого. Для Оберона есть и другие редакторы, в т.ч. и с запрашиваемыми вами фичами. Однако я даже не добрался до их использования, не то что реализации такого же функционала в XDev. Мне эти фичи просто не нужны. Я для XDev думал изначально стратегию развития "делаю всё, чего мне не хватает". Как у Linux'а. Но, видимо, времена уже не те и энтузиасты не те. Что поделать (пожимает плечами).

---------- Post added at 16:51 ---------- Previous post was at 16:09 ----------

Посыл Screw’а можно свести к трём пунктам.

1. Хочу крутых демок и игр на Обероне!

Я тоже. :) Но я не служба исполнения желаний. Хотите крутых демок и кроссплатформенных игр на Обероне? Пишите их. А я буду помогать, как помогал Slenkar’у (http://zx.oberon2.ru/forum/viewtopic.php?f=10&t=135). Кстати, его участие внесло свою лепту в плане мотивации сделать ZXDev лучше.

2. Оберон отстой

Подходить к ценности Оберона нужно с позиции его основных достоинств — простоты и минимализма. Если вы исповедуете другие ценности, юзайте Цы++ или асм.

Буквально пару дней назад прошло мероприятие Оберон-день в России 2015 (https://www.youtube.com/playlist?list=PLoKr-_Vv5yq4HkT6bVWtvs6lArek8KEGV). Иван Денисов демонстрирует применение Оберона для коммерческой разработки прибора для измерения слабых потоков светового излучения (https://www.youtube.com/watch?v=1CDTgMpH-ts&index=4&list=PLoKr-_Vv5yq4HkT6bVWtvs6lArek8KEGV). Прошивка для микроконтроллера и программа управления прибором разработаны на Обероне. Я определённо могу сказать, что IQ у Ивана Андреевича высокий, наукой занимается. Так что есть люди, не только не считающие Оберон отстоем, но использующие в своей практике.

Вот, кстати, тезис с мероприятия (https://www.youtube.com/watch?v=psyASrecA4s&list=PLoKr-_Vv5yq4HkT6bVWtvs6lArek8KEGV&index=1):

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

3. ZXDev отстой

ZXDev я разрабатывал в первую очередь для себя. Выложил и стал о нём рассуждать, возможно, зря — это многих нервирует. Видимо, я, начитавшись “Just for Fun” Торвальдса, буквально переоценил энтузиазм представителей ZX-сообщества. Не будем забывать и о специфическом отношении ZX-фанов к высокоуровневым средствам разработки:

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

У меня была надежда и на любителей Паскаля. Но вы же видите — Andrew, например, вместо того, чтобы воспользоваться каркасом ZXDev, допилить под себя по мелочам и наполнить своим собственным смыслом и видением, предпочитает изобретать свой компилятор недопаскаля, на что, впрочем, имеет полное право (как — и я рисовать кружочки, а не гнать пачками потрясающие мир игры).

Чтобы подчеркнуть сильную сторону именно XDev спрошу так: покажите мне простое средство разработки, позволяющее с одного листа собирать игры для ретро- и ново-платформ. Пусть оно даже будет чрезвычайно корявое. И заодно покажите мне пачки красивейших демок и игр, на нём разработанных и поражающих воображение.

Чтобы ZXDev стал намного лучше — нужна коллективная разработка. Один человек (особенно малопродуктивный программер типа меня) просто физически не может найти в себе мотивацию сделать всё запрашиваемое. Но тех, кто давно не смотрел в сторону ZXDev, уверяю — ZXDev уже далеко не тот, что был в начале его обсуждения. :) В хорошем смысле.

Хорошо, давайте так: какие фичи вы бы хотели увидеть в новой версии? Всё исполнить не обещаю, но почему бы вместо наездов не присовокупить немножко и конструктива?

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

jerri

24.09.2015, 17:15

jerri, когда-нить допишу. ;) Но он вряд ли вызовет ажиотаж у людей типа Screw’а.

да он и супротив Чуреры или АГД поделок может ажиотажа не вызвать.
Но он все еще не написан. хотя то что ты показывал было уже играбельное. не?

Хочется уже посмотреть как оно будет выглядеть.

Опять же, я не ставлю цели кого-то переплюнуть и всех поразить невиданной игрой. С какой стати? С тем же успехом я могу спросить: ты когда допишешь все проекты, которые задумывал?

в 2014 я выпустил l'Abbaye des Morts
в 2015 я написал Bathyscaphe

в каждой игре своя идея и реализация.

если все пойдет как задумано то думаю будет еще одна игра в 2015
так что как бы вот...

А у Screw’а с огромным негодованием спрашиваю: я всю жизнь мечтал о порте игры Commander Keen для спека. Вы почему её до сих пор не сделали? ХАЧЮЮЮЮЮ!!! ;)

Ну что то я не помню что Screw анонсировал Commander Keen для Спека.
Да и не помню что его вообще кто-то анонсировал. Так что тут твоя риторика мимо тазика.

Oleg N. Cher

24.09.2015, 21:46

Но ведь Screw требует то, чего я тоже не анонсировал и никому не обещал. Как и тебе скорейшего релиза болдердаша, jerri. А список я просил не у тебя, а у Screw. Кстати, я не знаю, разрабатывает ли он игры. Но и он не знает, разрабатываю ли я. Поясню. Меня игры интересуют только как образцы работающего кода. С позиции его красивости.

Как я подхожу к философии разработки ZXDev. Это не попытка внедрить всё, чего бы хотелось видеть в современной IDE. Это, скорее, отталкивание от самого необходимого, ретроспективный обзор всего моего опыта разработки с постепенным выкристаллизовыванием понимания того, что необходимо на самом деле. Я, например, очень доволен возможностью генерировать с помощью WinDev сверхмалые exe, но это так, к слову.

Теперь вот идёт запрос фичи. У меня уточнение. Это значит что вы будете пользоваться ZXDev с этой фичей? Или это просто пожелание "а вдруг привлекёт кого..." Не привлекёт. У Boriel's ZX Basic'а нету никакого интелисенса, у него даже банального IDE нет. Что не мешает народу штамповать игры и софт в удивительных масштабах. Правда, исходники часто просто кака - смесь асма с непонятно чем. Я бы таких исходников постеснялся. Тоже к слову.

Сейчас болдердаша (как и порта Дурачка) ждёт примерно 0 человек. Дарк Вудса, рискну предположить, ожидает как минимум Reobne, потому что он делал звук для этой игры. С этой позиции логичнее доделать Вудс. Однако ещё у меня недоработанный вывод кружочка (хеллоу Screw! ), недоотлаженная процедура заливки и куча своих собственных идей, например, крайне необходимо портировать в среду утилиту Watson для расширенного просмотра интерфейсов. Теперь начинать изобретать что-то потому что кому-то лень кликнуть три раза и редактор с подстановкой ключевых слов скачать? (тем более, никто, как я понимаю, ZXDev юзать и не собирался, просто s_kosorev мысль высказал). Я даже ссылку дам (http://forum.oberoncore.ru/viewtopic.php?f=30&t=2027&start=60), тестируйте. И помогу собрать консольную версию Ofront'а для винды, если нужно. Или начать делать порт XDev для линукса для человека, который всё равно пользоваться этим не будет? Если будет - сделает сам, я буду только рад. И помогу, чем смогу. Вот так всё грустно обстоит. У меня десятки направлений. Та же KOL для Оберона, та же ACL. Всё начато, намечено. Возможно, я хватаюсь за всё подряд, распыляюсь и не хватает концентрации. Ну так это моя проблема как разработчика. Кому до этого дело. Я вообще читал на хабре, что серьёзные проекты лучше малыми силами не делать — глохнут от отсутствия мотивации. Как-то так.

Так что определённо я - не лучший представитель Оберон-сообщества. Но уж какой есть, звыняйте. Для развития Оберона нужны такие люди как Иван Денисов, вот это образец энтузиаста. Вот кстати вам ещё ссылочка на его разработку - программу Генератор алмазных шаров (http://diaball.molpit.com). Сделана ессно тоже на Обероне (вернее, на Компонентном Паскале).

jerri

25.09.2015, 09:56

Но ведь Screw требует то, чего я тоже не анонсировал и никому не обещал. Как и тебе скорейшего релиза болдердаша, jerri. А список я просил не у тебя, а у Screw. Кстати, я не знаю, разрабатывает ли он игры. Но и он не знает, разрабатываю ли я. Поясню. Меня игры интересуют только как образцы работающего кода. С позиции его красивости.

давай посмотрим что хотел screw

Итак:
1) оберон мощный
2) проекту идет 4ый год
3) на обероне можно писать прекрасные игры, особенно кроссплатформенные.

Покажите мне их. Покажите полезный софт. Пролистав 10 последних страниц я увидел только какой-то маразм с очисткой экрана и рисованием кружочка.

ну разве он от тебя требует невозможного?
есть что-нибудь полезное написанное на спектрум на обероне?

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

Но если на Обероне для спектрума за 3 года до сих пор нет ни одного завершенного проекта (даже самого простого) то что я подумаю про Оберон?

У Boriel's ZX Basic'а нету никакого интелисенса, у него даже банального IDE нет. Что не мешает народу штамповать игры и софт в удивительных масштабах. Правда, исходники часто просто кака - смесь асма с непонятно чем. Я бы таких исходников постеснялся. Тоже к слову.

Boriel дал людям то что они хотели.
быстрый и удобный способ совмещать бейсик (для взимодействия и быстрого написания логики) и ассм (там где требуется скорость)
для тех кто не хочет писать на чистом ассме.
А уж как оно выглядит в исходнике так ли уж важно?

Сейчас болдердаша (как и порта Дурачка) ждёт примерно 0 человек. Дарк Вудса, рискну предположить, ожидает как минимум Reobne, потому что он делал звук для этой игры. С этой позиции логичнее доделать Вудс. Однако ещё у меня недоработанный вывод кружочка (хеллоу Screw! ), недоотлаженная процедура заливки и куча своих собственных идей, например, крайне необходимо портировать в среду утилиту Watson для расширенного просмотра интерфейсов. Теперь начинать изобретать что-то потому что кому-то лень кликнуть три раза и редактор с подстановкой ключевых слов скачать? (тем более, никто, как я понимаю, ZXDev юзать и не собирался, просто s_kosorev мысль высказал). Я даже ссылку дам (http://forum.oberoncore.ru/viewtopic.php?f=30&t=2027&start=60), тестируйте. И помогу собрать консольную версию Ofront'а для винды, если нужно. Или начать делать порт XDev для линукса для человека, который всё равно пользоваться этим не будет? Если будет - сделает сам, я буду только рад. И помогу, чем смогу. Вот так всё грустно обстоит. У меня десятки направлений. Та же KOL для Оберона, та же ACL. Всё начато, намечено. Возможно, я хватаюсь за всё подряд, распыляюсь и не хватает концентрации. Ну так это моя проблема как разработчика. Кому до этого дело. Я вообще читал на хабре, что серьёзные проекты лучше малыми силами не делать — глохнут от отсутствия мотивации. Как-то так.

Так что определённо я - не лучший представитель Оберон-сообщества. Но уж какой есть, звыняйте. Для развития Оберона нужны такие люди как Иван Денисов, вот это образец энтузиаста. Вот кстати вам ещё ссылочка на его разработку - программу Генератор алмазных шаров (http://diaball.molpit.com). Сделана ессно тоже на Обероне (вернее, на Компонентном Паскале).

насчет болдердаша - его жду я.
насчет Вудсов их ждет Reobne.

основные плюсы оберона про которые ты рассказывал это кроссплатформенность и скорость разработки.

---------- Post added at 10:56 ---------- Previous post was at 10:14 ----------

так где там скорость?

Sergey

25.09.2015, 12:07

jerri

25.09.2015, 13:52

Screw & Jerri, ваше метаутверждение, что Оберон не является действенным кроссплатформенным средством разработки программ, аргументируемое отсутствием чего-либо написанного на нём за целых 4 года, НЕСОСТОЯТЕЛЬНО.
Вы исходите не из технических возможностей системы, а из статистики её использования, которая складывается под влиянием не только объективных, но и субъективных факторов. Вы понимаете, что НЕЛЬЗЯ принудить кого-либо к его использованию?
Как бы вам нагляднее пояснить...
Вот, к примеру, Python - разве плохой язык программирования? Или Ruby? Но я не могу на них писать, - я ненавижу их синтаксис. Он мне органически не подходит. Но это не даёт мне оснований хаять эти языки, утверждая, что они не эффективны.
Я бы, может, написал что-нибудь на обероне, - но не пишу, - причина та же, - не ложится на душу синтаксис. Так получилось, что мне ПРИЯТНЕЕ писать на Сях, асме, REXX.

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

Так что я все еще жду портированный с БК0010 на языке Оберон Болдераш
А Reobne ждет Dark Woods.

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

Sergey

25.09.2015, 14:23

1.

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

... было мнение, что но Обероне можно быстро и удобно писать программы. Вот и хотим оценить скорость и удобство. А заодно читабельность исходников и эффективность получаемого кода.
Я один вижу противоречия между первым и последующими утверждениями? ;)

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

Ответ тут очень простой, на самом деле. Что, на Обероне нельзя написать верно работающую программу? - нет, - объективная реальность говорит, что можно. Тысячи их. Почему же на IDE Олега ничего не написано тогда? - да НЕ ОКАЗАЛОСЬ в спектрумовской среде поклонников Оберона. Сишников хоть одним местом ешь, а оберонщиков - нема. Вот и весь сказ. Развели тут, понимаешь... :)

jerri

25.09.2015, 15:08

Sergey, у меня нет желания спорить с тобой по поводу Оберона и ТСа.
Ты присоединился к обсуждению Оберона сильно позже меня.
Если так интересно просто перечитай все все обсуждения и споры про Оберон.

вот тебе ссылка http://zx-pk.ru/search.php?searchid=6761072

И поймешь и мои вопросы и его ответы...
и также вопросы остальных людей кто участвовал в этой дискуссии

и кстати вот вся информация по игре DASH (http://zx.oberon2.ru/dash.htm) предоставленная ТС
там нет никаких тап или сна файлов. хотя на картинках игровой процесс как бы идет.

Oleg N. Cher

25.09.2015, 22:57

есть что-нибудь полезное написанное на спектрум на обероне?Ну, я клип поздравительный написал. Ссылка была выше. Очень полезный. ;)

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

Но если на Обероне для спектрума за 3 года до сих пор нет ни одного завершенного проекта (даже самого простого) то что я подумаю про Оберон?Это вообще твоё дело - что про Оберон думать. Но проекты есть. Выше я сказал про клип. В поставке ZXDev идёт три простых портированных игры, они вполне закончены. Не тянут? Ну звыняй. ;)

быстрый и удобный способ совмещать бейсик (для взимодействия и быстрого написания логики) и ассм (там где требуется скорость) для тех кто не хочет писать на чистом ассме.
А уж как оно выглядит в исходнике так ли уж важно?Важно.

Понимаешь, языки высокого уровня как бы придумали для того, чтобы отделить мух от котлет. Мне стиль работы на Си или Boriel'е для ZX не нравится тем, что там логика перемешана с кусками на асме, портировать такие игры тяжело, ну чуть конечно полегче, чем с асма, но это не тот вид, понимаешь? Если ты не видишь смысла портировать игры со спека - я вижу. Это работа с любимым кодом, это приятно, будит ностальгию и т.п. ;)

так где там скорость?jerri, я понимаю как тебе это трудно понять. Но попробуй. Если ты имеешь талант к игроделанию – это не значит, что я его тоже имею. Душу нужно чувствовать к делу. У меня душа есть к вылизыванию алгоритмов, к коду. Не к игроделу.

Я не знаю, как устроена двойная и тройная буферизация графики, я не работал с расширенной памятью даже 128 кб моделей спека, я никогда не делал продвинутой графики и анимации. Или там звука на AY. И не имею никакого желания во всё это вникать. Чуете куда клоню? У меня требуют того, что я не умею и никогда не умел.

Даш – это простая как пять копеек игра. Взята просто как макет для того, чтобы убедиться, что средств Оберона будет достаточно для повторения её логики. Это исследование. Убедился. Доводить макет до качества релиза как бы смысла нет, не находите?

Я специально написал откровенно выше: как я работаю как кодер и какие у меня проблемы с доводкой проектов. Это не характеризует Оберон-языки. Это характеризует меня – чего я хочу добиться своей деятельностью и как могу действовать.

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

Sergey, благодарю за понимание.

goodboy

25.09.2015, 23:08

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

Oleg N. Cher

26.09.2015, 03:24

онанизмом тоже занимаются для получения удовольствия,
только вот дети (игры) от этого не-получаютсяЗничит люди, не делающие игр (для спектрума) - онанисты? Пойдите всем об этом расскажите, goodboy. :)

и кстати вот вся информация по игре DASH (http://zx.oberon2.ru/dash.htm) предоставленная ТСИ, кстати, не вся, вот ещё:

http://zx.oberon2.ru/forum/viewtopic.php?f=27&t=38

Там есть ссылка на реп, куда я вчера сделал коммит. И где, кстати, показан каркас процесса разработки даша для java micro edition. Это работающий макет, который можно наращивать по вкусу. Но если вдруг интересует продукт уровня пуребасика - то это не ко мне. Или ко мне, но предоставьте штат грамотных сотрудников и инвестора.

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

;)

В этом и мощь Оберона. Он затачивается под всё малыми силами. Если они достаточные конечно. Для ZX они недостаточны. Потому что делать библиотеку с тройной буферизацией вывода графики асмеры для ZXDev не хотят, потому что кодинг на ЯВУ для ZX - отстой. А писать на Обероне другие люди для ZX тоже не хотят, потому что нет библиотек, в частности, для тройной буферизации вывода графики. И пусть jerri меня научит сверхскоростной разработке библиотек, может как-нить без асма можно? И без знания тонкостей программинга AY? Может AY в Оберон уже должен быть вшит, как и работа со страницами памяти всех моделей спека? Где здесь выход, господа? :)

jerri

26.09.2015, 09:19

http://zx.oberon2.ru/forum/viewtopic.php?f=27&t=38[/url]

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

хммм.
видимо ты мои посты не читаешь.
жаль жаль очень жаль.

в мокапе кстати было больше Даша.

jerri

26.09.2015, 09:24

Даш – это простая как пять копеек игра. Взята просто как макет для того, чтобы убедиться, что средств Оберона будет достаточно для повторения её логики. Это исследование. Убедился. Доводить макет до качества релиза как бы смысла нет, не находите?

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

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

я понял что сам ты написать библиотеку не сможешь. А тот кто сможет - не напишет. Ты его не убедил.

goodboy

26.09.2015, 09:29

Зничит люди, не делающие игр (для спектрума) - онанисты? Пойдите всем об этом расскажите, goodboy.
сравнение было с людьми которые (по их рассказам) что-то делают в-своё удовольствие, но толку от их трудов не-видно

Oleg N. Cher

26.09.2015, 12:35

сравнение было с людьми которые (по их рассказам) что-то делают в-своё удовольствие, но толку от их трудов не-видноХорошо, goodboy. Возьмём даже не онанизм, а безопасный секс, которым 100% людей занимаются исключительно ради удовольствия. Они все конечно делают это безо всякого видимого толку для ZX-сообщества и вас лично. Или вы пропагандируете секс исключительно для зачатия, как у кришнаитов? Или не видите, что ностальгирующие фанаты, ретро-геймеры и прочая братия того же толка, что и я, просто Обероном не занимается. Некоторые в своей жизни не писали игр, только запускали их. Но осуждения вашего не вызвали.

но ты ее даже не написал. ты сказал что пишешь и не написал.Так пишу. Я тебе даже ссылку на реп дал, глаза протри родной?

И все картинки разработки что ты показывал видимо являются просто картинками.jerri берёт меня на слабо, причём делает это в той же манере, что и годы назад. История всё хранит, посты можно поднять, jerri. И тогда я ему давал желанный не тап, а трд, и он его даже запускал и, кажется, даже ругал или хвалил качество кода как более или менее удовлетворительное. И тогда же он меня упрекал, что, дескать, это картинка, а не код. Ну что же, вот опровержение. Это было просто, jerri. ;)

я понял что сам ты написать библиотеку не сможешь. А тот кто сможет - не напишет. Ты его не убедил.Я уже написал довольно много библиотек. И перенёс в ZXDev то, что меня интересовало. Не тебя, jerri. Ну давай возьмём дыбу или там раскалённые клещи. И поубеждаем. ;)

jerri, и заметь. Я от тебя не требую чтобы ты разрабатывал игры на ZXDev и писал для него библиотеки. А ты от меня требуешь, причём с негодованием и пеной у рта. Зачем ты присвоил себе это право, на которое, очевидно, у тебя нет никаких оснований? Смени тактику. Загрузи и посмотри ZXDev, в нём уже реализовано много хороших идей. И тогда ты будешь очень чётко понимать изнутри в каком направлении его следует развивать. А так твой трёп, как ты сам выражаешься, мимо тазика - голый никому не нужный онанизм в стиле гудбоя.

jerri

26.09.2015, 13:49

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

Аллилуйя, за три года он научился пользоваться вложениями.

а теперь, пожалуйста, покажи пост где ты выкладывал TRD, а я его смотрел.
Тебе найти пост с вложением (твоим) будет проще чем мне.

Andrew771

26.09.2015, 14:21

Олег, я тебе писал уже раньше, чтоб библиотеку создавал сам. Никто другой этого пока не хочет делать. Я же создал для своего Паскаля ее всю сам. Да, потратил почти год, но создал все процедуры. Некоторые взял у других, которые сложные или долго писать (например, умножение и деление 16-битных чисел). Ты также поступай. И накидай демо-примеров небольших.
Процедуры почти все уже созданы за много лет, поищи тут: http://zxdn.narod.ru и http://zxpress.ru
У меня тоже можешь взять - файл libasm.lib.

Oleg N. Cher

26.09.2015, 16:57

Андрей, демо-примеры есть, библиотеки есть. Несложные игры а-ля LaserBasic или Supercode делать можно. Вроде бы от среды разработки на ЯВУ для ZX большего и не надо?

Я адаптировал всё, что мне было нужно. И продолжаю это в своём скромном темпе. Хотите довести ZXDev до уровня коммерческого продукта - помогайте, чёрт возьми. Или не жалуйтесь. Я не Андрею это говорю.

---------- Post added at 16:57 ---------- Previous post was at 16:07 ----------

а теперь, пожалуйста, покажи пост где ты выкладывал TRD, а я его смотрел.
http://zx-pk.ru/showpost.php?p=475114&postcount=28

Обновил страничку http://zx.oberon2.ru/dash.htm. Выложил демку и фрагмент кода. Исходники недоделанного Даша, по крайней мере в полном объёме, шарить пока не намерен. Возвращаться к вдумчивой доработке Даша сейчас по Вашему тебованию не считаю нужным, поэтому поругивайте что увидите.( потом трд был оттуда убран мною )

jerri пишет (http://zx-pk.ru/showpost.php?p=479254&postcount=107):

от тебя на просьбу показать "DASH" для спека в исходниках и обьектнике видно только скриншоты нарисованные в пейнте.

Я пишу (http://zx-pk.ru/showpost.php?p=484545&postcount=125):

сообщаю, что товарищ jerri не заметил давно ещё неделек 2-3 назад выложенный снап Даша, но негатив свой высказать поторопился. Ну разве ж я в этом виноват.

jerri пишет (http://zx-pk.ru/showpost.php?p=484565&postcount=126):

Oleg N. Cher, не будь снобом я не сижу на твоем сайте с нетерпением ожидая когда ты на нем что-нибудь выложишь.
...
качество и размер сделанного с помощью sdcc оценил и мне оно в целом не нравится. после оценки готового продукта мое присутствие здесь больше не требуется и отвечаю я тебе только если ты меня призываешь.Разумно, изыди! ;)

Ты ещё тогда писал, что не видишь смысла в использовании Оберона для ZX. Как видим, ты оказался прав. Ты его действительно не увидел и продолжаешь не видеть. Зачем же и тогда, и теперь пеной исходишь? :) Успокойся и иди кодить на животворящем асме, как всегда. И пусть ничто паскалеподобное (свят-свят изыди сатана!) не потревожит твой покой.

Кстати, про онанизм - гудбою посвящается (http://zx-pk.ru/showpost.php?p=475276&postcount=39):

не надо ёрничать, спектрум мертв и заниматься им - фанбойство
потому все что делается здесь - делается для удовольствия

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

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

Так что вижу нишу для кроссразработки на Обероне для Спека. А ещё Оберон может помочь использовать хорошие Спектрум-наработки на других платформах. И вести одномоментную разработку одной программы на одном языке для Спека и, например, для Win32/Linux. Это тоже возможно. Заявляю как оберонщик и спектрумист.Прошли года, а воз и ныне там.

jerri

26.09.2015, 17:28

А
http://zx-pk.ru/showpost.php?p=475114&postcount=28
( потом трд был оттуда убран мною )

а 3 экрана все так же лежат ага.
выложил бы сразу сюда - вопросов бы не было.

jerri пишет (http://zx-pk.ru/showpost.php?p=484565&postcount=126):

ты бы еще подсократил взяв одно из предыдущих сообщений и вот это. было бы еще веселее.

Ты ещё тогда писал, что не видишь смысла в использовании Оберона для ZX. Как видим, ты оказался прав. Ты его действительно не увидел и продолжаешь не видеть. Зачем же и тогда, и теперь пеной исходишь? :) Успокойся и иди кодить на животворящем асме, как всегда. И пусть ничто паскалеподобное (свят-свят изыди сатана!) не потревожит твой покой.

я, пеной? не смеши мои тапочки. ты принимаешь желаемое за действительное.

Прошли года, а воз и ныне там.

кому как
черера появилась (http://www.mojontwins.com/juegos_mojonos/la-churrera-english/), AGD немерянно развился (http://arcadegamedesigner.proboards.com/)

движуха идет да.

Andrew771

26.09.2015, 20:44

Андрей, демо-примеры есть, библиотеки есть. Несложные игры а-ля LaserBasic или Supercode делать можно. Вроде бы от среды разработки на ЯВУ для ZX большего и не надо?
Да не хотят уже писать ничего. На ZX Like Pascal тоже. Вроде ALKO порывался делать игру, даже попросил процедуры зеркалирования спрайтов добавить, я добавил, но с тех пор молчок. Мы сами для себя пишем, для собственного фана. У меня в перспективе было написание Цивилизации на Паскале, пока запала нет после Эйфории два-дэ. Заметил, что и другие меньше стали писать, чем в 2010-2013 годы.

Oleg N. Cher

26.09.2015, 20:52

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

jerri, на примере BEEP'а пойми простую вещь: главный затык в скорости разработки игр (мною) заключается не в проблемах уровня Оберон-кода, а вообще в специфике спектрума, в том, что кодить библиотеки приходится в основном на асме. И кодить вещи, которые у меня плохо получаются. Например, для Даша нужно сэмулировать некоторые низкоуровневые возможности ДОС. Ты кинулся мне помогать? Нет. Так чего ты ещё от меня хочешь?

мой интерес уже исполнен, я увидел что хотел.
у меня к конверсии игр подход абсолютно другой.У меня к конверсии игр подход абсолютно буквоедский. Т.е. я добиваюсь не внешнего подобия как, например, Destr, а работаю именно с оригинальным кодом. Это касается и Даша. Кстати, скорость разработки Дарк Вудса страдает именно от того, что этот проект в первую очередь базируется на реверс-инжиниринге исходной игры. jerri знает секрет как ускорить процесс реверс-инжиниринга? Вот то-то же. И нефиг все издержки разработки на ZXDev списывать на язык. Он великолепен и очень помогает мне уйти от косяков Си. Хотя и не настолько хорошо (взять хотя бы баги моего бэк-энда - SDCC, которые приходилось править, тратя на это много времени; тоже, кстати, потеря, не связанная с Обероном, не находишь, jerri?)

s_kosorev

26.09.2015, 22:44

Он великолепен и очень помогает мне уйти от косяков Си.
Так называемые "косяки" Си, это результат общения с Pascal like языками, на самом деле если ими проникнуться, они позволяют меньшими затратами делать многие вещи, под затратами, я в первую очередь имею ввиду объем кода для процессора и что немаловажно для спектрума, это выливается в производительность.

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

Отсюда и возможности допустить ошибку больше, но если сравнивать с ассемблером, заменой которой является Си, то количество ошибок как мнимум на 2-3 порядка меньше.

Паскаль подобные языки свое наилучшее продолжение получили в C#, на Си подобный синтаксис можно не смотреть, идеология языка от паскаля, C# опять же не может просто делать те вещи которые можно было делать на Си

Eltaron

27.09.2015, 11:53

Паскаль подобные языки свое наилучшее продолжение получили в C#
Ваще рядом не лежали. С# - это улучшенный C++.

s_kosorev

27.09.2015, 12:59

Ваще рядом не лежали. С# - это улучшенный C++.
-Компонентность на уровне стандартной либы: C# да, delphi да, с++ нет
-Библиотеки на основе экспорта типов и метаданных: c# да, delphi да, с++ нет
Развитый RTTI: C# да, delphi да, с++ нет
-ссылки для объектов и максимально исключение указателей: C# да, delphi да, с++ нет
-строки, динамические динамические массивы на уровне языка: C# да, delphi да, с++ нет
-property да еще и во главе угла: C# да, delphi да, c++ нет
-множественное наследование: C# нет, delphi нет, c++ да
-наличие управления автоматического управления памятью: C# да, delphi местами, c++ нет

Общего у с++ и C# местами похожий синтаксис, на этом все, с дельфи гораздо более родственные души, если отбросить синтаксис, так практически близнецы

Eltaron

27.09.2015, 13:53

Ну так можно дойти до того, что все современные языки - клоны паскаля. У python тоже практически всё это есть, тоже близнец? :)

Принципиальные вещи, которые сходу в голову приходят
строки мутабельны: паскаль да, шарп нет
value types можно передавать как объекты: паскаль нет, шарп да
generic types - паскаль нет, шарп да, вдохновлены шаблонами c++
ковариация массивов - паскаль нет, шарп да

ссылки для объектов и максимально исключение указателей: C# да, delphi да, с++ нет
Вообще ж писать на плюсах с указателями - это значит не знать плюсов. Они там только для совместимости.

Andrew771

27.09.2015, 14:39

А че писать то, код это вообще не проблема
А Copperfeet с Alone этого не знали, поэтому писали годами один и тот же проект. :)

s_kosorev

27.09.2015, 14:51

строки мутабельны: паскаль да, шарп нет
в с++ вообще строк нет

value types можно передавать как объекты: паскаль нет, шарп да
var pint: ^Integer; так что можно,
ps: хотя нет, это указатель, boxing unboxing нет (если не брать в расчет последние delphi)

generic types - паскаль нет, шарп да, вдохновлены шаблонами c++
это как говорить что самолет был вдохновлен телегой, так то он так, но общего кроме абстрактного понятия, а оно таки движется

В с++ шаблоны compile time, т.е. хитросделаные макросы, в C# параметрический полиморфизм и ноги растут не от с++ а от какого то функционального языка, от с++ взяли синтаксис, в delphi generics есть, в с++ если в целом то нет.

Andrew771

27.09.2015, 21:03

А че писать то, код это вообще не проблема
Вот что по этому поводу пишет Вяч.Медноногов в своей эпопее про Черного Ворона (http://pmg.org.ru/gamedev/epic1.htm):

Большой прикол в том, что наиболее трудные места пишутся сначала на Cи на РС, а потом переносятся в ассемблер (ручками, конечно). Получается быстрее и надёжнее. В следующий раз думаю целиком сначала на ИБМ состряпать, а только потом - перенести на ZX
Жаль, тогда еще не было кросс-компиляторов ЯВУ для Спектрума. А сегодня уже есть!

jerri

27.09.2015, 23:18

jerri знает секрет как ускорить процесс реверс-инжиниринга?

шта? Jerri знает про реверс инжинеринг очень много.
чтобы не быть голословным он даже поделится с тобой ссылкой
вот те раз (https://www.dropbox.com/s/3cpq2va820vi2g7/%D0%91%D0%90%D0%A2%D0%98%D0%A1%D0%9A%D0%90%D0%A4.b in?dl=0)
вот те два (https://www.dropbox.com/s/16tu6efqx3docx7/Batiskaf.idb?dl=0)
вот те три (https://www.dropbox.com/s/5qp4ca32f2wbtzl/bathyscaphe.scl?dl=0)

если кликнуть по ссылкам там будут файлы. Файлы, Карл, их сразу можно использовать. Не ссылки на форумы или картинки.

Хотя и не настолько хорошо (взять хотя бы баги моего бэк-энда - SDCC, которые приходилось править, тратя на это много времени; тоже, кстати, потеря, не связанная с Обероном, не находишь, jerri?)

ты правда считаешь что для написания этой игры у меня было всё?
я переписал столько разного интересного инструментария
например вот (https://www.dropbox.com/s/7jip5wsxw2huxl4/batiskaf.pb?dl=0)или вот (https://www.dropbox.com/s/2lk7x2tvu4bkuv8/bat_map.pb?dl=0)

как то так

Oleg N. Cher

27.09.2015, 23:22

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

s_kosorev, так называемые "косяки" Си - это результат общения не только с Паскалем, но с Си в первую очередь, причём общения очень плотного и тесного, сидения в отладчике, переноса кода между платформами и т.п. Как переносимый ассемблер он вполне хорош и по сей день, хотя мог бы быть и получше. Но если роль (удельный вес) в софте ассемблера с течением лет уменьшался, то сегодня людям всё в меньшей степени нужен и переносимый ассемблер. Щас вот набегут спорить, ну ладно, пусть это будет моё субъективное мнение. Языки Java, C# прикрепили к платформе и назвали это кроссплатформенностью. PHP, Perl прикрепили к интерпретатору и назвали так же. Ну пусть. Хотя мне всё равно не нравится. Людям подавай быструю разработку софта. Так что я не стал бы идеализировать язык, который никак не возбраняет накосячить в самом что ни есть прикладном куске кода. На нём будто по минам ходишь каждый свой миг, притом то же самое можно сказать и о Паскале в редакции Дельфи/FPC.

Про Оберон скажу так: он в силу концепта более безопасен. Нету ручного освобождения памяти. Нет возможности из прикладного кода залезть не в свою память. Вообще нельзя. Физически. Получается managed код, притом без всяких виртуальных платформ. Это всё притом на синтаксисе Паскаля базируется. Ессно эти все возможности не про честь ZX, но тут уже что поделать. Мне нравится, господа, когда об Обероне рассуждают как о взрослом языке, который может посягнуть на место не только C++, но и C#, и всё это заслуженно. И оберонщики понимают проблемы Оберона. Посмотрите выступление Рифата на Оберон-дне 2015 (https://www.youtube.com/watch?v=SslOw9B2-UA&list=PLoKr-_Vv5yq4HkT6bVWtvs6lArek8KEGV&index=6) (это автор компилятора Exaprog Oberon-07 (http://exaprog.com)) - он высказал очень здравые вещи и про IDE, и про необходимость пошагового отладчика. Всё это нужно, просто делать некому. Вот так вот. s_kosorev, обязательно посмотрите, пожалуйста. Я не против навороченного IDE. Кстати, можно было бы собрать его на основе плагинов Саши Ильина. Просто мне не надо, я обхожусь БлэкБоксом. А делать впрок вдруг кому-то понадобится - это большая роскошь даже для богатых фирм.

Ещё моментик. Даже если выкинуть Оберон - ZXDev остаётся самой крупной подборкой ZX-библиотек, адаптированных для использования из SDCC. И в этом смысле проекту могли бы помочь любители Си, а вовсе не Оберона, однако почему-то они этого не делают. Кроме Sergey, который предложил библиотеку для работы с TR-DOS (http://zx.oberon2.ru/forum/viewtopic.php?f=10&t=139), и SfS - библиотеку для вывода спрайтов libspr (http://zx.oberon2.ru/forum/viewtopic.php?f=10&t=198), которые я адаптировал для ZXDev. Респект!

s_kosorev

28.09.2015, 10:35

Языки Java, C# прикрепили к платформе и назвали это кроссплатформенностью.
На самом деле в битве кросплатформенных инструментов победил js.

Нету ручного освобождения памяти. Нет возможности из прикладного кода залезть не в свою память. Вообще нельзя. Физически.
Во первых можно, во вторых сейчас таких языков много, очень много, в третьих, блокирование прямого обращения к памяти не увеличивает надежность, есть еще много разных средств/методик/технологий, повышающих надежность ПО.
У от nasa кстати java на слуху и на марс и на луну и просто полетать. А так читал где то, что nasa если не связано с полетами то использует во всю Python

Получается managed код, притом без всяких виртуальных платформ.
C#, java можно компилировать в нативный код при помощи утилит, MS уже из коробки для C# сделала нативную компиляцию, пока для UniversalApp но обещают для всего.

Оберон - ZXDev остаётся самой крупной подборкой ZX-библиотек, адаптированных для использования из SDCC.
если не ошибаюсь, на данный момент самый большой сборник библиотек это z88dk

Vitamin

28.09.2015, 11:14

Побуду адвокатом дьявола.

Развитый RTTI: C# да, delphi да, с++ нет
"Развитый" - это что именно? Ибо RTTI какбэ в C++ имеется.

-строки, динамические динамические массивы на уровне языка: C# да, delphi да, с++ нет
Что значит "на уровне языка"? Для с++ есть std::string. Если считать, что это не в языке, а в стандартной (ключевое слово, если что) библиотеке, то для шарпа/явы строки тоже являются производными типами.

-наличие управления автоматического управления памятью: C# да, delphi местами, c++ нет
Если предположить, что "автоматическим управлением памяти" называется сборщик мусора, то где его места у delphi?

в с++ вообще строк нет
Да ну?

В с++ шаблоны compile time, т.е. хитросделаные макросы, в C# параметрический полиморфизм и ноги растут не от с++ а от какого то функционального языка, от с++ взяли синтаксис, в delphi generics есть, в с++ если в целом то нет.
А щто, у нас определение параметрического полиморфизма уже пополнилось требованием быть сугубо runtime?

msm

28.09.2015, 11:33

Олег, выскажу свое ИМХО по поводу Оберона.

Да, с некоторыми доводами я согласен. Но ИМХО главная проблема паскальподобных языков не в плохих IDE и не в плохих отладчиках. Самая большая проблема, которую я вижу - необходимость объявлять переменные и константы в отдельном блоке, а не максимально близко к месту использования. Чем это чревато? А чревато *****кодом, который идет сплошняком от тех, кто долго посидел на паскалеподобных языках.

row[i].col[j].getPerson().getName();
row[i].col[j].getPerson().getLastName();
row[i].col[j].getPerson().getMiddleName();
row[i].col[j].getPerson().getPosition();

И тому подобный копипаст идет сплошняком на паскалеподобных проектах. И самое нехорошее, что человека, который вот так привык писать - потом хрен переучишь, он такое считает нормальным. Пока это не исправят, Оберон ИМХО лучше не рассматривать вообще. Хотя я видел проект что то вроде Оберон под .NET - там в принципе все есть, вполне хороший язык. Вот только это .Net с другим синтаксисом и ничего больше.

Bedazzle

28.09.2015, 12:22

row[i].col[j].getPerson().getName();
row[i].col[j].getPerson().getLastName();
row[i].col[j].getPerson().getMiddleName();
row[i].col[j].getPerson().getPosition();

Это от незнания конструкции with.

msm

28.09.2015, 13:08

with здесь помогает, но не сильно. Во первых уровень вложенности появляется на пустом месте. А этих псевдопеременных может запросто быть штук 5 - 5 уровней вложенности на ровном месте? Или неоднократная копипаста with в пределах метода?

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

Короче, это искусственные сложности на ровном месте. Тут собственно вполне промышленные языки вроде C++, Java, C# зачастую критикуют за слишком громоздкий синтаксис.

s_kosorev

28.09.2015, 14:17

"Развитый" - это что именно? Ибо RTTI какбэ в C++ имеется.
хотя бы как в Qt

Что значит "на уровне языка"? Для с++ есть std::string.
Встроенный в язык тип, var s:string; public string s;

Если предположить, что "автоматическим управлением памяти" называется сборщик мусора, то где его места у delphi?
не сборщик, подсчет ссылок на объекты и начало процесса уничнотежения объекта когда счетчик в 0 перешел

Да ну?
в языке нет, есть строковые константы

А щто, у нас определение параметрического полиморфизма уже пополнилось требованием быть сугубо runtime?
естественно

Vitamin

28.09.2015, 15:11

хотя бы как в Qt
Это будет нарушением одного из освновополагающих принципов С/С++ - ты не платишь за то, что не используешь.

Встроенный в язык тип, var s:string; public string s;
А разве в C#/Java он встроенный?

не сборщик, подсчет ссылок на объекты и начало процесса уничнотежения объекта когда счетчик в 0 перешел
И где такое в делфях?
В плюсах - читать про std::shared_ptr.

естественно
И где это определение? Ссылочку, пожалста.

s_kosorev

28.09.2015, 15:38

Это будет нарушением одного из освновополагающих принципов С/С++ - ты не платишь за то, что не используешь.
ну и договорились, в с++ нет нормального RTTI

А разве в C#/Java он встроенный?
да

И где такое в делфях?
когда с ссылками на объекты работаешь, деталей уже не помню честно, 10 лет назад на дельфи программировал, подзабылось, суть если не напутал, при копированни ссылки счетчик увеличивается, при выходе из области компилятор finally вставляет втихую и вызывает уменьшение счетчика ссылок, как то так

В плюсах - читать про std::shared_ptr.
да я понимаю что в с++ можно все что в дельфи сделать, но там это встроенное в crt либо сахаром на уровне компилятора + crt

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

Vitamin

28.09.2015, 16:01

да
Тогда почему он является вполне себе производным классом, живущим в стороннем пакете, а не в синтаксисе языка как int/long/char?

когда с ссылками на объекты работаешь, деталей уже не помню честно, 10 лет назад на дельфи программировал, подзабылось, суть если не напутал, при копированни ссылки счетчик увеличивается, при выходе из области компилятор finally вставляет втихую и вызывает уменьшение счетчика ссылок, как то так
Это справедливо только для СОМ-объектов. Что суть мегакостыль, в отличие от С++, где автоматические деструкторы вызываются всегда. Что и позволяет сделать любой вариант подсчета ссылок.

блин потерял все свои 20томов определений, тут логики достаточно, какой это полиморфизм, если оно все упадет если подсунуть собраную где то за углом библиотеку с типом наследником от известного типа.
И с чего оно должно падать?
Runtime полиморфизм: внешний код живет в стороннем бинарнике, но должен обеспечивать определенный интерфейс (т.е. быть его наследником). Так можно сделать плагинную систему. Проблемы могут быть только в различных ABI компиляторов.
Compile-time полиморфизм: внешний код доступен в виде исходников, обеспечивающих требуемый интерфейс (набор полей и/или методов).

В чем проблема?

s_kosorev

28.09.2015, 16:58

Тогда почему он является вполне себе производным классом, живущим в стороннем пакете, а не в синтаксисе языка как int/long/char?
что бы однообразный интерфейс был, в яве/шарпе к value типам еще много чего довешено в нагрузку, и это не определение типов а хаки, алиасы на внутренние типы

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

Compile-time полиморфизм:
это вообще костыль, я хочу бинарные библиотеки продавать

Так можно сделать плагинную систему. Проблемы могут быть только в различных ABI компиляторов.
то биш нихрена нет в C++, а слишком много если, они на то и "если"

C# скомкомпиленая mono будет кушать и не подавится библиотеками скомпилеными любой версией MS компилятора, даже dotGNU или Roslyn, delphi, foxpro все побоку, так как есть спецификация на методанные

Oleg N. Cher

28.09.2015, 17:10

если не ошибаюсь, на данный момент самый большой сборник библиотек это z88dkНе ошибаетесь. Но я имел в виду ZX-библиотек для работы из SDCC, что и обозначил. SDCC имеет лучшую кодогенерацию из всех открытых компиляторов для Z80.

Самая большая проблема, которую я вижу - необходимость объявлять переменные и константы в отдельном блоке, а не максимально близко к месту использования.А вот тут я конкретно не соглашусь. Традиция модульных языков - это отделение декларативной секции от императивной, и это имеет свои преимущества - видно все переменные, которые используются в процедуре, они имеют единообразный стиль порождения, что помогает избегать *****кода в духе { int i; bla-bla-bla { int i; ... }}. По поводу многословности паскалеподобных языков много говорилось, и проблема надумана восприятием сишников, которые прощают своему любимому Си описания типа const a = 1; const b = 5; (const 2 раза!) extern int a; static char b; void fn(int a, int b, int c, int d) (int 4 раза! в Паскале можно было бы a, b, c, d: INTEGER ), но отчаянно при этом хают паскалевские секции CONST и VAR. Как по мне - Паскаль явно не поощряет *****кодить, я даже на себе ловил не раз, что на Паскале хочется чище оформлять исходники, хотя, возможно, это и психологический фактор, не буду спорить.

Владислав Фольц внедрил в Оберон расширение - объявление переменной по месту - в компиляторе Оберон-07 для js. В том-то и прелесть, Оберон не статичен, делается под задачи. И под вкусовщину конечно наверно тоже можно.

Vitamin

28.09.2015, 17:55

что бы однообразный интерфейс был, в яве/шарпе к value типам еще много чего довешено в нагрузку, и это не определение типов а хаки, алиасы на внутренние типы
Почему же алиасы? Вполне себе полноценные врапперы вокруг примитивных типов. Но они не в языке опять же, равно как и String.
Так что не грузи про отсутствие строк в С++.

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

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

C# скомкомпиленая mono будет кушать и не подавится библиотеками скомпилеными любой версией MS компилятора, даже dotGNU или Roslyn, delphi, foxpro все побоку, так как есть спецификация на методанные
И что тебе мешает поддержать эту спецификацию для бинарных библиотек на С++?

s_kosorev

28.09.2015, 18:16

видно все переменные, которые используются в процедуре, они имеют единообразный стиль порождения,
тут тоже вопрос, я по стилю программирования люблю очень много временных переменных с осмысленными именами, может быть банально 20 переменных в процедуре

Например (C#)

var projectFiles = FileService.SearchProjectFiles(solutionRoot);
var parseResult = ProjectService.AddFiles(projectFiles);

if (parseResult.Any())
{
var errorMsg = ErrorLogingService.CreateFormattedErrorList(parseR esult);
ErrorWin.Show(errorMsg);
}

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

тем более формальный тип который скрывается под var, без выведения типов, может быть примерно такой

ProjectName.Backend.Solution.Modules.SolutionLoade r.Services.SolutionLoaderBase

---------- Post added at 18:16 ---------- Previous post was at 18:00 ----------

Но они не в языке опять же, равно как и String.
ну я тебе доктор, выдумал себе что то и доказываешь, еще раз, тип string в .net это buildin тип, что бы с ним как то можо работать, хаками сделали интерфейс как будто string это обычный класс. пруф? на http://referencesource.microsoft.com/#mscorlib/system/string.cs
найди там указатели, работу с байтами или еще что то. Если совсем интересно станет можно в CIL посмотреть еще.

В таком случае, в С++ тоже есть "частично" автоматическое управление памятью.
Ну я раз за С++

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

И что тебе мешает поддержать эту спецификацию для бинарных библиотек на С++?
Потому что C++ не описывает специфики бинарных файлов хотя бы, да и вообще это тянет на библиотеку эмулирующиую дотнет, так можно сказать что C# может 1C код нативно выполнять

Vitamin

28.09.2015, 19:31

найди там указатели, работу с байтами или еще что то. Если совсем интересно станет можно в CIL посмотреть еще.
Не обязательно. Даже несмотря на мое полное профанство в шарпе, прекрасно понимаю код:

unsafe public char[] ToCharArray() {
// <STRIP> huge performance improvement for short strings by doing this </STRIP>
int length = Length;
char[] chars = new char[length];
if (length > 0)
{
fixed (char* src = &this.m_firstChar)
fixed (char* dest = chars) {
wstrcpy(dest, src, length);
}
}
return chars;
}

Поле m_firstChar - первый символ строки. Так что std::string тоже можно считать встроенным в С++. О чем, собственно, и написано в msdn, раз уж ссылки на него:

Строго говоря, в языке C++ отсутствует встроенный строковый тип; в типах char и wchar_t хранятся отдельные символы — для имитации строки необходимо объявить массив этих типов, добавив конечное значение NULL (например, ASCII ‘\0’) к элементу массива за последним знаком (также называется "строкой в стиле C"). Строки в стиле C требовали написания гораздо большего объема кода или использования внешних библиотек служебных функций. Однако в современном C++ имеются стандартные библиотечные типы std::string (для 8-разрядных символьных строк типа char) или std::wstring (для 16-разрядных символьных строк типа wchar_t). Эти контейнеры STL можно рассматривать как собственные строковые типы, поскольку они являются частью стандартных библиотек, имеющихся в любой совместимой среде сборки C++.

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

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

s_kosorev

28.09.2015, 19:47

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

Еще раз для тех, кто на бронепоезде: от ABI зависит исключительно бинарная совместимость, а не возможность использования полиморфизма как такового.
Блин, ты или тролишь так или я хз, иди матчасть что ли учи, когда поймешь разницу между обобщенным программированием и параметрическим полиморфизмом, тогда продолжим, меня умиляют ++программеры, они думаю познали плюсы значит познали мир, на все накладывают плюсы как эталон. Не стоит думать что все что похоже на ++ было скопировано и переиначено, есть много других моделей.

Vitamin

28.09.2015, 20:10

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

, и опять же, тут идет копирование из одного встроенного типа в другой.
Ага. Одним встроенным типом является неявный массив, другим- явный.

Блин, ты или тролишь так или я хз, иди матчасть что ли учи, когда поймешь разницу между обобщенным программированием и параметрическим полиморфизмом, тогда продолжим
Не троллю. А говорю, что в С++ параметрический полиморфизм обычно реализуется с помощью обобщенного программирования. О чем, собственно, говорит википедия (https://ru.wikipedia.org/wiki/Полиморфизм_(информатика)#.D 0.9F.D0.B0.D1.80.D0.B0.D0.BC.D0.B5.D1.82.D1.80.D0. B8.D1.87.D0.B5.D1.81.D0.BA.D0.B8.D0.B9_.D0.BF.D0.B E.D0.BB.D0.B8.D0.BC.D0.BE.D1.80.D1.84.D0.B8.D0.B7. D0.BC)

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

Screw

28.09.2015, 20:14

Т.е. проблема только в отсутствии единомышленников ? Я знаю как минимум одного: http://rsdn.ru/forum/flame/1214478

В этом треде не менее эпично раскатывают С/С++ в блин, авторитетно обьясняя преимущества Оберона. Думаю, Сергей бы проникся ZXDev и влился в стройные ряды разработчиков.

Oleg N. Cher

28.09.2015, 23:59

О, Сергей Губанов - очень серьёзный и известный оберонщик и физик, может даже доктор наук, я точно не в курсе. Он для спектрума кодить не будет. Зато он - автор подсистемы для раскраски синтаксиса для БлэкБокса, которую я использовал в XDev. Так что косвенно он уже участвует.

Да, Оберон-сообщество довольно малочисленное.

---------- Post added at 23:59 ---------- Previous post was at 23:48 ----------

Про объявление переменных по месту. Delphi и FreePascal уже довольно зрелые среды разработки, но ничего подобного объявлению переменных по месту в них не внедрено, хотя внедрено много чего другого. Это вопрос культуры кодинга. Список переменных одним блоком - это как бы секция данных процедуры. Помните выражение "алгоритмы и структуры данных"? Так вот, алгоритмы - то, что после BEGIN, а данные - VAR. И это здорово, что секция данных декларативна, а не размазана по исполняемому коду неизвестно как. Это дисциплинирует имхо. Учит думать более структурно, в терминах "алгоритм отдельно, данные отдельно". Ну да пусть это будет моё имхо и ничего больше.

И ещё знаете что меня удивляет. Что в Паскаль пытаются внедрить какие-то рюхи из плюсов, но даже не смотрят в сторону убирания лишних BEGIN'ов в духе Модулы-2 и Оберона. Да, нарушится совместимость. Но нет, это необязательно - можно ввести обероновские фичи доступными по специальной директиве типа (*Oberon+*)

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

msm

29.09.2015, 09:59

Про объявление переменных по месту. Delphi и FreePascal уже довольно зрелые среды разработки, но ничего подобного объявлению переменных по месту в них не внедрено, хотя внедрено много чего другого. Это вопрос культуры кодинга. Список переменных одним блоком - это как бы секция данных процедуры. Помните выражение "алгоритмы и структуры данных"? Так вот, алгоритмы - то, что после BEGIN, а данные - VAR. И это здорово, что секция данных декларативна, а не размазана по исполняемому коду неизвестно как. Это дисциплинирует имхо. Учит думать более структурно, в терминах "алгоритм отдельно, данные отдельно". Ну да пусть это будет моё имхо и ничего больше.

Вопрос только - нужно ли в наше время думать структурно. Во времена создания Паскаля структурное программирование действительно было прорывом. Но с тех пор было множество других прорывов. Изменились условия и изменилась элементная база. Сейчас, за счет того, что уперлись в рост тактовой частоты и появилась ставка на параллелизм, в тренде функциональное программирование. Да, там var не в почете, но всякие val, def вовсю используются. Уже по 8 ядер даже в мобильниках, в видеокартах вообще бешенный уровень параллелизма - сейчас совершенно другие концепции, сейчас нужно не каждый такт и байт считать, сейчас чтоб не тормозило нужно как то использовать сразу все ядра, и крайне желательно без синхронизации, чтоб был параллелизм а не concurrency. В императивном программировании тоже совершенно другие концепции, которые были в 70-е годы. Не циклы со счетчиком, а итераторы, например - уже давно стандарт.

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

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

Но насколько я знаю, языки Оберон семейства претендуют на большее, чем использование в ретрокомпьютерах. И в этих условиях я ни черта не понимаю, зачем так цепляться за with. Ну можно было бы для обратной совместимости оставить секцию var. Но также внести оператор val как в scala - хуже от этого точно не будет, это прекрасная замена with. И в циклах со счетчиками тоже разрешить объявлять переменные без явной секции, например тоже как val. Варианты есть для того, чтобы сохранить обратную совместимость, но при этом язык сделать более удобным.

Я понимаю почему это все не было сделано в 70-е годы. Все таки тогда нужно было на маломощных машинах это все компилировать, и компилятор нужно было держать как можно более простым чтоб он занимал и использовал как можно меньше памяти. Но сейчас то даже для ретрокомпьютеров никто в здравом уме не будет писать непосредственно на ретрокомпьютерах, ну совершенно нет в этом необъодимости. Потому компилятор можно усложнять без проблем.

Oleg N. Cher

29.09.2015, 19:07

Семантика WITH в Обероне отличается от паскалевской. В Паскале with применяется для сокращения длины кода при обращении к группе элементов записи - что-то вроде ручной оптимизации. В Обероне WITH - это охрана типа - безопасное приведение родителя к потомку, которое вызывает исключение если оно некорректно.

TYPE
ChlenSemyi = RECORD END;
Syn = RECORD (ChlenSemyi) END;
Doch = RECORD (ChlenSemyi) END;

VAR semyanin: POINTER TO ChlenSemyi;
BEGIN
...
WITH semyanin: Syn DO (* Вот здесь вылетит, если семьянин - не сын *)

У простого компилятора есть достоинства. Его легче дорабатывать малыми силами, переориентировать на другие платформы, обфичивать, наконец. Вы просто привыкли к готовым фирменным инструментам, которые делаются огромнейшими силами. Кстати, я не верю в прогресс. Я верю скорее не в то, что скоро мобильники стоядерные будут у каждого, а в то, что люди заползут в пещеры и скатятся к каннибализму. Оптимист я, понимаете. Но это так, отступление.

---------- Post added at 18:46 ---------- Previous post was at 18:37 ----------

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

Я, занимаясь настройкой компов, заметил, что состояние компьютера напрямую зависит от уровня интеллекта человека, его использующего. У "охламонов" всё кучей и навалом - чёрт ногу сломит, фильмы - куски vob'ов, скопированные с DVD не целиком, шансон вперемешку с фотками "я бухаю на днюхе" и остатками когда-то установленных игр. У интеллектуалов - учителей, студентов - порядка на компе гораздо больше. Всё разложено по папочкам, которые аккуратно названы и т.д. Если вам не нравится такая аналогия с программистами, не парьтесь, как говорится.

---------- Post added at 19:07 ---------- Previous post was at 18:46 ----------

Хочу приятно порадовать сишников и плюсистов, которые пару лет назад с пеной у рта доказывали мне, что в Си есть модульность. Таки свершилось (http://zx.oberon2.ru/forum/viewtopic.php?f=25&p=1510)! ;) Фича, которая была в Модуле-2 30 лет назад - теперь и в C++, и это очень прогрессивно, господа. Я правда рад. И не издеваюсь. Только вопрос: если в Си уже была модульность, то что они тогда ввели, в чём, так сказать, цимес? ;)

Alcoholics Anonymous

30.09.2015, 08:10

Не ошибаетесь. Но я имел в виду ZX-библиотек для работы из SDCC, что и обозначил.

SDCC можно использовать из z88dk теперь дает ему доступ к значительной части z88dk библиотек :) SDCC в сочетании с z88dk генерирует двоичные файлы 5-50% меньше, но чаще всего в диапазоне 10-20%. Программы, которые используют библиотеки кода см крупнейшие сокращения в размере и улучшения в скорости.

sdcc can be used from z88dk now, giving it access to a large part of the z88dk libraries :) sdcc in combination with z88dk generates binaries 5-50% smaller but most typically in the 10-20% range. Programs that make use of library code see the largest reductions in size and improvements in speed.

SDCC имеет лучшую кодогенерацию из всех открытых компиляторов для Z80.

Это не то, что четкая. SDCC генерирует код плохое, когда дело доходит до контакта с статика, длинных и поплавков. sccz80 генерирует лучший код для этих трех случаев. Дело статика очень важно, потому что для того, чтобы получить лучшую производительность скорость-мудрый и размер мудрый на z80, программы должны делать, как много локальных переменных, как разумно в статике. z88dk добавил много правил глазок специально для улучшения управляемости SDCC в статики и теперь в точке, где SDCC может генерировать примерно такой же код, как размер компилятора sccz80 z88dk, когда имеем дело с статике. До этого, SDCC был генерации кода на 10% больше, чем sccz80 почти все время и размер кода очень проблема при программировании на C на z80. Теперь это только порождает гораздо большую код для длинных и поплавков, которые менее важные случаи.

It's not that clear-cut. sdcc generates poor code when it comes to dealing with statics, longs and floats. sccz80 generates better code for those three cases. The statics case is very important because in order to get the best performance speed-wise and size-wise on the z80, programs should be making as many local variables as reasonable into statics. z88dk has added many peephole rules specifically to improve sdcc's handling of statics and it is now at a point where sdcc can generate approximately the same size code as z88dk's compiler sccz80 when dealing with statics. Before that, sdcc was generating code 10% larger than sccz80 almost all the time and code size is very much a problem when programming in C on the z80. Now it only generates much larger code for longs and floats which are less important cases.

Единственное, SDCC действительно есть движение для него это единственный компилятор Z80 С, что близко к / пытается быть полностью соответствуют стандартам. Я считаю, это намного удобнее использовать для этой причине, и что функция, вероятно, очень важно для проекта, который переводит к C в качестве промежуточного шага.

The one thing sdcc does have going for it is it's the only z80 C compiler that is close to / attempting to be fully standards compliant. I do find it much more comfortable to use for that reason and that feature is going to be very important for a project that translates to C as an intermediate step.

shurik-ua

30.09.2015, 15:47

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

Oleg N. Cher

01.10.2015, 03:54

Okay, okay, you have convinced me, Alcoholics Anonymous! z88dk is very cool. :) You did a good work.

Хочу ещё за многоядерность и функциональное программирование сказать для msm. Как всегда Оберон впереди планеты всей - Юрг Гуткнехт, понимая направление развития железа, делает ОС A2/AOS/Bluebottle и многопоточный диалект Active Oberon, обладающий очень легковесными потоками, они намного легче тредов (нитей) и процессов Windows и fork UNIX/Linux - где-то ~ в 30 раз эффективнее, но цифру говорю наобум, если интересно - загуглите. Притом AO делается маленьким коллективом. Т.е. Оберон удалось легко перенацелить и применить для многопроцессорных систем, запараллеливание делается ядром системы и исходники, основанные на активных объектах, работают одинаково хорошо и на одном ядре CPU, и на 8-и. В случае с любимыми нами C++, C#, Java (я не знаю, насколько хорошо они готовы к большому количеству ядер и насколько трудно будет переписать существующие программы) - эти языки будут затачиваться на это огромными силами, и мы, как всегда, не имеем никакой возможности влиять на направление этого процесса, как всегда смутно догадываясь почему запад всё время нас опережает в технологиях и где тут собака зарыта. Но только лишь смутно.

ФЯ я особо не занимался, но с моей невысокой колокольни я не вижу особых ниш для их применений. Ядро ОС? Нет. Мобильные приложения? Тоже нет, там процы ещё слабоваты. Микрокотроллеры? Опять нет по той же причине. Веб-сайты? Нет. Прикладной софт для десктопов и ноутов для горизонтального рынка софта? Нет. Игры? Опять нет. Ну ладно, может быть частично, да. Выскоконагруженные сетевые сервера и веб-сервисы? Опять нет.

Барьер вхождения в ФЯ выше, чем в старое доброе императивное программирование. Ладно, может сейчас на ФЯ пишется много софта? Да нет же, хорошо если 1% от общей массы. Ниша эта - наука, главным образом. Так что рано ещё хоронить императивные языки, пожалуй.

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

s_kosorev

01.10.2015, 06:01

многопоточный диалект Active Oberon
не в кассу, Active Oberon это обычная модель многозадачности, ФП же позволяет по своей сути паралелить задачи

Я я особо не занимался, но с моей невысокой колокольни я не вижу особых ниш для их применений. Ядро ОС? Нет. Мобильные приложения?
ФП идеология другая, применять можно где и обычные языки, сейчас все языки мейнстрим сдвигаются в сторону ФП, immutable, лямбды в бизнез логике приложений уже как родные вжились, на лямблях к примеру вдоль и поперек lazy вычисления деляются, банально позволяет меньше ресурсов тратить.

Веб-сайты? Нет.
очень к месту кстати, сайты для тысяч клиентов, там более применимы чем обычные языки, вообще где асихронность по природе естественна там ФП вполне придиваются.

Ладно, может сейчас на ФЯ пишется много софта?
тут не только ФЯ, методики ФП сейчас применяются вдоль и поперек

---------- Post added at 05:56 ---------- Previous post was at 05:55 ----------

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

---------- Post added at 05:57 ---------- Previous post was at 05:56 ----------

Барьер вхождения в ФЯ выше, чем в старое доброе императивное программирование.
ничего подобного

---------- Post added at 06:00 ---------- Previous post was at 05:57 ----------

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

---------- Post added at 06:01 ---------- Previous post was at 06:00 ----------

ыскоконагруженные сетевые сервера и веб-сервисы? Опять нет.
Это вообще самая целевая точка применения ФП

Vitamin

01.10.2015, 12:30

они намного легче тредов (нитей) и процессов Windows и fork UNIX/Linux
А что насчет тредов (нитей) в UNIX/Linux? А то какое-то кривое сравнение...

В случае с любимыми нами C++, C#, Java (я не знаю, насколько хорошо они готовы к большому количеству ядер и насколько трудно будет переписать существующие программы)
Не труднее, чем переписать существующие программы на оберонах для той же цели. Кстати, как в обычном обероне с многопоточностью?

msm

02.10.2015, 20:16

Я бы поспорил относительно "впереди планеты всей". Сейчас в тренде далеко не многопоточность. Многопоточность в ЯП используется уже не один и не 2 десятка лет. Сейчас в тренде - параллелизм. Да и то, параллелизму тоже не один десяток лет. Параллелизм идет не только на уровне ядер процессора, но даже на уровне команд. SIMD инструкции массово появилисись еще в Pentium MMX, а скорее всего гораздо раньше. Вот только эффективно это все использовать не так то и просто. В видеокартах, в современных игрушках, параллелизм научились весьма эффективно использовать. В обычных приложениях параллелизм массовым пока не стал. И текущий передний край - это не многопоточность, а параллелизм. Параллелизм уже поддерживается языками программирования, всякие map, reduce, filter, scan из функционального программирования - как раз и решают задачи использования параллелизма в массовом обычном программировании. Но пока это все еще в зачаточном состоянии, хотя прогресс виден отчетливо.

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

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

Заменить ассемблер для ZX? В теории было бы неплохо. Вот только это до сих пор нерешенная задача для Z80. Даже компиляторы Си для Z80 генерируют весьма посредственный код. А чтоб генерировать оптимальный код сразу и по памяти и по скорости - нужны охрененные ресурсы.

Oleg N. Cher

03.10.2015, 00:45

А что насчет тредов (нитей) в UNIX/Linux? А то какое-то кривое сравнение...http://rsdn.ru/forum/design/816814.1
Кстати, вот (относительные) времена переключения контекстов процессов в Aos и в Linux

Aos 0.014
Linux 0.433

То есть, Aos-совские активные объекты работают в 30 раз быстрее чем если бы их эмулировали в Linux-е.
Вот ещё по теме ссылка: http://rbogatyrev.livejournal.com/9919.html

Не нужно мне задавать хитрых вопросов по многопоточности, я не специалист. За что купил - за то и продаю. Но замечу, что в отличии от Форта (на котором испытывали параллелизм на куче ядер (http://geektimes.ru/post/133291/)), языка для железа, Оберон - язык для человека; он читаем.

Кстати, как в обычном обероне с многопоточностью?Что значит "в обычном"? Какой-то кривой вопрос.

Оберон и Оберон-2 на уровне языка не предлагают никаких средств для многопоточности, оставляя это на откуп среде исполнения и библиотекам. Ровно также как C и C++. Это значит, что в среде Windows можно использовать механизмы, предлагаемые WinApi, в среде Linux свои и т.д.

Что касается диалектов, которые претендуют, так сказать, на "промышленное применение".

В Active Oberon - хорошо, для того и создавался.

В BlackBox можно так:

Параллельное программирование на языке Component Pascal – подсистема времени выполнения Active BlackBox (http://zx.oberon2.ru/lib/ErmakovIE/04_11_Ermakov.doc)

GPCP вообще поверх JVM и .NET, поэтому унаследовал их модель и механизмы.

Оберон - исследовательская площадка, поэтому есть экспериментальные решения (http://sourceforge.net/projects/ta1/). Но в основном в Оберон-парадигме приветствуется кооперативная многозадачность, как более надёжная и предсказуемая.

И.Е.Ермаков. О преимуществах кооперативной многозадачности (http://www.inr.ac.ru/~info21/zametki/1actions.htm)

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

Vitamin

03.10.2015, 12:25

http://rsdn.ru/forum/design/816814.1
Оттуда же:

SYG>То есть, Aos-совские активные объекты работают в 30 раз быстрее чем если бы их эмулировали в Linux-е.
ГВ>Извините, но сравнивать заведомо облегчённую реализацию с тяжёлыми процессами Linux по меньшей мере неверно, а по большей попахивает демагогией.
А>Вот тут позвольте не согласиться. Если бы в AOS присутствовали тяжёлые процессы, тогда да. А если лёгкие процессы AOS выполняют все те функции, которые в линуксе возложены на тяжёлые (и даже больше) — тогда это проблемы архитектуры линукса, и ничего некорректного здесь нет.
ГВ>AOS в принципе не решает задачу изоляции адресных пространств процессов, предлагая всего-то объектную модель всего-всего. Негусто, надо сказать
А>В AOS просто нет такой сущности как "процесс" в понятиях других систем. Активности несколько отличаются от процессов. К тому же по большому счёту в AOS нет и понятия "адресное пространство", т.к. нет адресов и адресной арифметики. Это, кстати, позволяет не заботиться о том, где расположен активный объект и что он вообще такое (активный объект может быть и устройством, "в железе", так сказать). Действительно, "негусто".
ГВ>Совершенно согласен. И потому не верно сравнивать процессы Linux и активные объекты AOS. А уж тем более — сравнивать какое-то виртуальное моделирование активных объектов процессами Linux. Это кому же в голову такая шальная мысль придёт?

И как итог, мнение оратора ГВ:

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

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

Оберон и Оберон-2 на уровне языка не предлагают никаких средств для многопоточности, оставляя это на откуп среде исполнения и библиотекам. Ровно также как C и C++. Это значит, что в среде Windows можно использовать механизмы, предлагаемые WinApi, в среде Linux свои и т.д.
Это понятно. Перефразирую: есть ли в вышеупомянутых оберонах библиотеки для организации многопоточности (работа с потоками, примитивы синхронизации и прочий IPC). И что насчет кроссплатформенности?

И, как по мне, это лучшее развитие программирования, чем подменять простые понятия сложными - итераторами, ленивыми вычислениями, "более эффективными" (Вы это сами проверяли?)
Представь себе, проверяли:) Разумеется, если возможности всего это не заложены в язык, то выглядит это довольно громоздко и слабочитаемо. Но это не отменяет эффективности подхода "если что-то можно не делать- не делай".

Kakos_nonos

03.10.2015, 12:31

Олег, подскажи какой-нибудь простой оберон для Windows, чтоб быстро компилировал. Можно только текстмод, без редактора (всё равно буду прикручивать свой). Захотелось попробовать, он примерно как паскаль, но вроде по-проще. Потом может под спек поизучаю, хотя я уже привык к асму. Надо будет сравнить скорость.

Мне кажется, сравнивать Оберон и Java/C# неправильно, Оберон - это простой минимальны язык, который просто изучить/реализовать, а Java и подобные - огромные монстры, на изучение/реализацию которых уходят годы.

Oleg N. Cher

04.10.2015, 11:55

Олег, подскажи какой-нибудь простой оберон для Windows, чтоб быстро компилировал.Если некритично, что закрытый, то:

XDS (http://www.excelsior.ru/products/xds) - Высококачественный оптимизирующий компилятор Модула-2/Оберон-2

Открытые:

• POW! (http://www.fim.uni-linz.ac.at/pow/) (по нему есть хорошая книга в торрент-раздаче (http://nnm-club.me/forum/viewtopic.php?p=6256036)). Есть инфа, что не инсталлится под Win64. Также может быть, что нельзя вызывать из консоли. Я просто не использовал.

Ну и вот этот компилер, выдернутый из BlackBox:

• Component Pascal Compiler for command-line (http://cp-dev.sourceforge.net)

Если интересует Оберон-07 (разберись, чем отличается этот диалект), то можно испробовать:

• Oberon-07/11 для Win32/Linux (https://sites.google.com/site/oberon07compiler/versii)
• Exaprog Oberon-07M (http://exaprog.com) (закрытый)

Что интересно - авторы обоих компилеров живы, русскоязычны и пинабельны.

Для Win64 есть ещё:

• AyaCompiler (https://github.com/congdm/AyaCompiler) - написан на себе и компилирует сам себя.

Мне кажется, сравнивать Оберон и Java/C# неправильно, Оберон - это простой минимальны язык, который просто изучить/реализовать, а Java и подобные - огромные монстры, на изучение/реализацию которых уходят годы.100%. Хотя уже то, что сравнивают, говорит в пользу Оберона. Значит сравнение уместно - ведь не сравнивают же C# с Laser Basic'ом.

крайне хреново сказывается на карме предмета сравнения (в данном случае, оберона и его диалектов).Vitamin, я же тебе сказал, что я не специалист по многопоточности. За что купил - за то и продал. Слышал, что Active Oberon реализует параллелизм, но насколько это кошерно в понимании трэнда - хз. Так что не брызгайся ;)

Это понятно. Перефразирую: есть ли в вышеупомянутых оберонах библиотеки для организации многопоточности (работа с потоками, примитивы синхронизации и прочий IPC). И что насчет кроссплатформенности?По поводу библиотек я тебе уже ответил. GPGP - JVM и .NET, AO - как на голом железе, так и поверх Win/Linux (на архитектуре x86, хотя делали компилятор и для ARM). BlackBox изначально для Win, но долизывается порт под Linux (x86), но ещё unstable.

Если тебе и правда интересно, то, что ты спрашиваешь, почему бы не погуглить? А то складывается впечатление, что абы попридираться.

s_kosorev

04.10.2015, 14:23

Слышал, что Active Oberon реализует параллелизм, но насколько это кошерно в понимании трэнда - хз
Active Oberon реализует многозадачность а не параллелизм, хотя в какой то мере эти вещи пересекаются.
Реализуется в AO многозадачность синтаксическим сахаром/конструкциями языка.

В ФП идеологии, при использовании imutable не нужна синхронизация по данным, которую АО реализует автоматом и создается впечатление что ей тоже нет, так как в ФП объекты не изменяются и создаются данные из одного потока. Этот подходов повышает параллелизм.

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

Vitamin

04.10.2015, 23:08

Если тебе и правда интересно, то, что ты спрашиваешь, почему бы не погуглить? А то складывается впечатление, что абы попридираться.
Ну это же не гугл нахваливает оберон как серебряную пулю от всех проблем, попутно обсирая альтернативы. О которых, кстати, можно было погуглить или спросить чтоб не выглядеть глупо при сравнении. Ах да, это сделало бы "соломенное чучело" не таким уж и соломенным.

Если что, против оберона как языка вообще ничего не имею.

Oleg N. Cher

05.10.2015, 22:18

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

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

msm, говоря о том, что "потоки, итераторы, словари, паттерн матчинг - это сейчас высокий уровень, а массивы и циклы - низкий", несколько лукавит и недоговаривает. Потому что если не массивы, то списки, а если не списки - то ячейки таблицы - это сегодняшняя предметная область, и таковой останется всегда. "Высокий уровень" в понимании msm не настолько самодостаточен, чтобы отказаться от "низкого уровня" в понимании же msm - "абстракций вроде массивов, циклов, условий". msm, ваши "итераторы" и проч. идут не "вместо", а "наряду с". Или поспорите?

---------- Post added at 22:15 ---------- Previous post was at 21:30 ----------

В книге "Языки программирования и методы трансляции (http://progbook.ru/technologiya-programmirovaniya/798-sverdlov-yazyki-programmirovaniya-i-metody.html)" есть развёрнутый на много глав обзор и анализ многих ЯП, вплоть до Форта, Лиспа, Пролога и Смолтока. И блестящее сравнение различных языков с Обероном. По этой книге обучают студентов в ВУЗах - на обложке есть герб с надписью "Допущено Министерством образования и науки РФ". Написал её Сергей Свердлов - человек очень умный и образованный, прекрасный программист. Так вот. Если кто-то желает понять что имеют в виду оберонщики, когда говорят о преимуществах этого языка над другими, вплоть до C# и Java, не поленитесь полистать данную книгу. В случае же Vitamin'а - очень твёрдый лоб просто. :) Кодит на десяти языках, пятнадцати апи под двадцать платформ прогу с одной логикой, но в лоб не видит проблем индустрии IT. А вот это и есть проблема. А если тебе не нравится как Губанов перегибает палку в похвальбах AO - иди набей ему морду. Мне высказывать своё праведное негодование не требуется, я за него не отвечаю. Также как и за остальных оберонщиков. :)

Kakos_nonos, из всех перечисленных компиляторов я предпочитаю свой XDev. На нём можно разрабатывать для Windows 32/64 bit - просто скачиваешь подсистему WinDev с репозитория (я её ещё не релизил). Если когда-то дойдут руки посмотреть - буду рад услышать мнение. И чего не хватает.

XDev/WinDev, во-первых, самый мультитаргетный из всех компиляторов Оберона (потенциально, на практике там ещё дофига работы) - за счёт использования Си. Во-вторых, он - самый оптимальный по кодогенерации - тоже за счёт Си. Но этими двумя критериями может похвалиться очень мало реализаций Оберона. Ну и полная реализация биндингов к WinApi есть только в XDS, BlackBox и XDev/WinDev.

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

---------- Post added at 22:18 ---------- Previous post was at 22:15 ----------

Ах да, забыл! Биндинги к WinApi ещё в POW! есть :)

Andrew771

05.10.2015, 22:23

Во-вторых, он - самый оптимальный по кодогенерации - тоже за счёт Си
не думаю, что Си помогает. Наоборот, мешает, добавляет свои извращения, ИМХО.
В общем, предлагаю схлестнуть наши компиляторы (XDev и ZX Like Pascal) лоб в лоб, тесты прогнать на целочисленных переменных и массивах. Посмотреть качество кодогенерации. :)

Для компании можно взять z88dk еще.

s_kosorev

06.10.2015, 09:04

Потому что если не массивы, то списки, а если не списки - то ячейки таблицы - это сегодняшняя предметная область, и таковой останется всегда
Это в дикие времена дельфи было и только на просторах СНГ.
Уже достаточно давно в ходу более адекватные реализации предметной областии, для сложных приложений Domain Model (http://habrahabr.ru/post/61524/), используются разные ORM (https://ru.wikipedia.org/wiki/ORM)

Sergey

06.10.2015, 09:09

Для компании можно взять z88dk еще.
Возьмите ещё и HiTech C v3.09, если можно.

msm

06.10.2015, 09:53

По поводу не "вместо", а "наряду с". И по поводу того, что Java, C# и т.д монстры. Вот не совсем так. Java, C# и практически любой язык, разве что относительно С++ можно поспорить из за черти каких костылей в виде поддержки обратной совместимости - это ОЧЕНЬ простые языки. И компилятор с нуля к ним пишется на раз 2 одним человеком. Вот только на чистом языке давно никто не кодит. Всегда используются библиотеки, которые в принципе считаются частью языка. В программировании есть принцип DRY - Dont Repeat Yourself. То есть не пиши одно и тоже каждый раз, нужно решать новые задачи, а не каждый раз копипастить старые. Стандартные (и нестандартные тоже) либы - это как раз то, что помогает сосредоточиться на задаче, а не на методах реализации. И в программировании, если код пишет не студент, и если разработчик развивался - в коде будут использоваться именно высокоуровневые абстракции, а не низкоуровневые конструкции языка программирования. Низкоуровневые конструкции - только при разработке кода наподобие библиотечного. В основном коде - только высокоуровневые конструкции. Да, и в принципе, любой из языков в начале жизни, что Java, что C#, что Python, что Ruby - прекрасно вместе с библиотеками пишется и поддерживается одним человеком.

Зачем же толпы народу работают над языком и платформой? А затем, чтоб язык был промышленным. Чтоб работало все шустро, компилятор должен быть не обычным, а оптимизирующим. Что весьма все усложняет.

Как там с библиотеками в Обероне? Можно ли на Обероне реализовать современные концепции с приятным синтаксисом? Монады, например. Паттерн матчинг. И тому подобное. Хороший язык позволит на нем реализовать практически любую концепцию, при этом использование этой концепции будет с приятным синтаксисом, легко читаемо и тому подобное. Например многие концепции на С++ хоть и можно реализовать, но через одно место, синтаксис получается полным дерьмом, и это недостаток именно языка. Аналогично с Java - многие вещи реализовать можно, но получается более громоздко по сравнению с другими конкурентами. А на Обероне, я так чувствую, будет еще более громоздко.

По поводу книг русскоязычных авторов, используемых в образовании в странах СНГ. К большому сожалению, преподавание ИТ в странах бывшего СССР отстало лет на 30 минимум. В российских ВУЗах программированию к большому сожалению не учат, там дают крайне устаревшую базу, и при этом дают весьма посредственно. Мне после окончании, например, пришлось практически полностью переучиваться, при этом постоянно занимаясь самообразованием, чтоб хоть как то быть в тренде программирования. Наибольший скачок понимания произошел в момент, когда я стал читать книги сразу на английском, а также когда смотрел на том же английском видеозаписи лекций буржуйских университетов - вот именно тогда я понял насколько хреново в России с преподаванием Computer Science. При этом проблема не в том, что типа старью учат. Проблема в том, что базу ни черта не дают. Преподаватели так и застряли в 80-х годах, игнорируя, что с тех пор многое изменилось. И потом специалистов ведущих ВУЗов с красным дипломом, участников олимпиад, приходится переучивать практически с нуля.

AlexG

06.10.2015, 11:18

Как там с библиотеками в Обероне? Можно ли на Обероне реализовать современные концепции с приятным синтаксисом? Монады, например. Паттерн матчинг. И тому подобное. Хороший язык позволит на нем реализовать практически любую концепцию, при этом использование этой концепции будет с приятным синтаксисом, легко читаемо и тому подобное.
А кто Вам сказал что ОБЯЗАТЕЛЬНО надо "Монады, например. Паттерн матчинг. И тому подобное." и еже с ними в корячивать в разные языки программирования. У каждого языка своя сфера применения. ровно как и у каждой методики программирования своя сфера.
Как применит (к примеру "Монады") к реализации UDP-протокола ?
То что хорошо для работы с базами данных - не работает с алгоритмом управления лампочкой в подъезде.

msm

06.10.2015, 12:26

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

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

Если брать ретрокомпы, например ZX, тут да, особо не разгуляешься. Пока (скорее всего в ближайшие лет 50 минимум) - только низкий уровень. Потому тут в принципе ниша для Оберон подобных языков есть. Вот только это крайне узкая ниша.

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

AlexG

06.10.2015, 13:37

Oleg N. Cher

06.10.2015, 14:00

В общем, предлагаю схлестнуть наши компиляторы (XDev и ZX Like Pascal) лоб в лоб, тесты прогнать на целочисленных переменных и массивах. Посмотреть качество кодогенерации. :)

Для компании можно взять z88dk еще.Это безусловно полезное предложение. Вот только наверно логично будет брать не ZXDev, а сразу SDCC?

Sergey, HiTech C v3.09 - последняя доступная версия? Как его юзать - из под эмуля Profi с CP/M или можно под каким-то эмулятором CP/M?

( что-то мне с трудом верится, что компилятор 80-х годов, занимающий пару десятков Кб, обойдёт SDCC по плотности кода )

---------- Post added at 14:00 ---------- Previous post was at 13:52 ----------

Как там с библиотеками в Обероне?Знаете, слабенько. Многие библиотеки (например, для работы с XML или VisualOberon для GUI) есть только для отдельных реализаций Оберона, ибо используют местные расширения. Я же говорю - писать некому, сообщество маленькое.

Можно ли на Обероне реализовать современные концепции с приятным синтаксисом?Смотря что считать приятным. Но будет громоздко, да. И без кучи фигуристых скобок, которые уже не одно поколение программеров считает неизменным атрибутом приятного синтаксиса. Если углубиться в это, то в Обероне нет конкатенации (в КП есть). Приходится писать:

String.Concat( String.Concat(a, b) , c);И, вероятно, это будет ваш приговор громозкости синтаксиса Оберона. :) А он просто простой язык.

Монады, например. Паттерн матчинг.Не скажу за патерн матчинг - не знаю, что это такое. Если бы сказали по-русски - может я бы понял. Но вот взять декларативный язык запросов к БД - SQL. Его не встраивают в другие языки на уровне синтаксиса. Зачем. Просто работают с ним из библиотек. Это как раз и есть Оберон-вей. В том числе и всякую функциональщину с лямбдами можно так реализовать, если потребуется.

Так что, повторюсь, Оберон-библиотек существует очень мало. В реализациях типа XDev можно подключить и использовать сишные.

s_kosorev

06.10.2015, 16:42

String.Concat( String.Concat(a, b) , c);
для чистых строк можно и покороче записать a+b+c, зато если a,b,c массив или коллекция строк, уже гораздо лаконичней получается.

---------- Post added at 16:42 ---------- Previous post was at 16:40 ----------

Его не встраивают в другие языки на уровне синтаксиса. Зачем. Просто работают с ним из библиотек.
Минимум 2 языка знаю где встраивают X++ (https://ru.wikipedia.org/wiki/X%2B%2B) и linq (https://ru.wikipedia.org/wiki/Language_Integrated_Query#.D0.9F.D1.80.D0.B8.D0.BC .D0.B5.D1.80) в C#

Sergey

06.10.2015, 17:15

Sergey, HiTech C v3.09 - последняя доступная версия? Как его юзать - из под эмуля Profi с CP/M или можно под каким-то эмулятором CP/M?
последняя. Официально свободная. работает из под эмуля для DOS (командная строка Windows).

( что-то мне с трудом верится, что компилятор 80-х годов, занимающий пару десятков Кб, обойдёт SDCC по плотности кода )
c версией 3.5 почти не сравнивал, а SDCC v3.4 нервно курит в сторонке. :)

s_kosorev

06.10.2015, 17:18

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

Oleg N. Cher

06.10.2015, 19:13

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

Я тут нагуглил, что для Active Oberon есть компилятор PACO (http://www.oberon.ethz.ch/archives/languagearchive/compilers_new). Расшифровывается Parallel Compiler. Так что всё-таки наверное в AO параллелизм, а не просто многопоточность?

Также на форуме Oberoncore людям удалось запустить параллельные вычисления в среде BlackBox на многокластерной и многоядерной машине - через какую-то готовую библиотеку для этого.

Господа, у вас слово Оберон вызывает какие ассоциации? У Vitamin'а - наверное хочется прибить Oleg N. Cher'а :) Слово Java вызывает у американцев приятные воспоминания о вкусе кофе, а у меня почему-то образ загорелой красавицы легко одетой, но это так, отступление. Маркетолог сказал бы, что Оберон распространяется плохо из-за неверной маркетинговой стратегии, и конечно же был бы прав.

Вы читали какие-нить произведения в жанре киберпанк? Там обычно хакеры-одиночки "ангелы", которые иногда собираются в группы, чтобы что-нить похачить, противостоят мега-корпорациям. Так вот я бы не хотел такого мрачного будущего для всех нас. Однако сравнивать возможности корпораций и одиночек - это вообще неправильно. Путь эволюции программера-одиночки в руках его самого. А корпорации всегда требуют играть по их правилам (писать на чём скажут). Оберон - язык не для корпораций. Даже если вдруг корпорация займётся им - она перекроит его до неузнаваемости. Рассматривайте проект XDev как попытку переосмыслить программирование на доступном для средних способностей индивида уровне. Без претензий на паттерн-матчинг. ;)

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

Что такое по своим качествам язык Оберон в ряду остальных?

Ф. В. Ткачёв когда-то показывал его место на плоскости из двух осей: быстродействие (=комплируемость) и гибкость (расширяемость).

Часть языков группируются вдоль первой оси, часть - вдоль второй (динамические языки) - и очень мало - в верхнем правом углу. Как пример проблемы - постоянная гибридизация пар языков, допустим, в игрострое или системных задачах, или "научке" - одного быстрого для ресурсоёмкой части (С++, например) и второго, удобного для скриптования и интерактивной работы (Python, Lua, Юникс-скрипты всяческие - тот Python, TCL/Tk, Shell). Оберон оказывается именно в этом углу. Спорный вопрос - кто там ещё и насколько сопоставим, но что таких немного - это понятно. Те же Java и C# сейчас обыгрывают Оберон по быстродействию только за счёт эффективных новых реализаций и отсутствия инвестиций в современные компиляторы Оберона. Обыгрывают с супер-сложными рантаймами, нивелирующими их языковые проблемы (типа только динамических структур и т.п.). Если же считать одной из составляющих гибкости-расширяемости не только рефлексию и динамическое связывание компонент - а ещё и общую простоту... Ведь что легче сопровождать и развивать, на протяжении двух-трёх десятков лет? И для написания сиюминутного "клея" что легче использовать (если человек берётся за программу раз в полгода - что ему легче вспомнить?)

Я бы выделил для выяснения места Оберона в ИТ-экосистеме другие 3 оси:

Простота - жёсткость - расширяемость.

Жёсткость - в смысле возможности создать статически проверяемый "каркас жёсткости" для программы. Как приятное следствие - возможность разрабатывать "почти готовое ПО" без обильного покрытия тестами каждого мелкого кубика.

Трудно найти много соседей Оберону в верхнем дальнем углу этих трёх осей.

Жёсткость - расширяемость: Ada, C#, Java, Haskell

Простота - жёсткость: ну, это скорее к языкам прошлого поколения (Modula-2, старый Pascal, нераздутый Fortran в некоторой мере, наверное...)

Простота-расширяемость: Лиспы всякие, Луа и прочие.

А всё вместе? Только что-то близкое, та же Modula-3. Может быть, нечто из компактного статически типизированного компилируемого функционального (OCaml какой-нибудь?).

Далее, недавно отвечал для себя на вопрос о различиях между той же Modula-3 и КП. Modula-3 нравится и на "оторванный от конкретики", чисто эстетический взгляд может смотреться более гармоничной. Однако что-то где-то лично меня напрягает. Как с теми же перечислимыми типами и проч.: вроде, для инженера и "эстетично, надёжно" и т.п. Но... Потом сформулировал своё ощущение: это уже попытка дать какие-то базовые вещи, полезные для предметных областей, для выражения семантики задачи. Но это скользкий путь - ибо задачи столь многообразны, что любые такие кубики быстро начинают жать (кому-то ещё и единицы измерения нужно контролировать - и чем больше зарываешься, тем более многообразия. Единицы измерения же контролировать можно уже с таким количеством нюансов, что не сделаешь заранее ничего, пригодного для широкого круга задач). Отсюда становимся на путь не определять в языке, а давать определять части языка динамически - и получаем взрыв безумия типа Nemerle и ко. Таким образом, имеет смысл вообще исключить из языка всё, сколь-нибудь ориентированное на прикладную специфику. А оставить языку 3 функции: 1) классно абстрагировать от физической машины, при этом оставляя полную прозрачность в отображении на императивный вычислитель; 2) давать "рёбра жёсткости" - средства статического контроля, позволяющие отсеять процентов 80 наиболее досаждающих ошибок, не гоняясь за каждой остальной мелочью, коих туча разных. Не нужно думать, что от контроля прикладной семантики мы отказываемся. Всегда есть возможность заложить уже свои рёбра жёсткости в фреймворках, чтобы уже защитить себя от каких-то нарушений прикладной семантики. 3) Давать средства расширения (полиморфизм и динамическое связывание), пригодных для безболезненного включения в систему компонентов, неизвестных на этапе её создания. Эти 3 функции в точности и оставлены в том же КП. При этом КП расширен над Обероном только по линии этих 3 функций, никаких "реверансов" в сторону прикладной семантики.Читать дальше (http://forum.oberoncore.ru/viewtopic.php?f=6&t=5267#p89900)

Oleg N. Cher

06.10.2015, 23:20

И вот с этой позиции, которую я горячо поддерживаю, внедрение SQL прям на уровне синтаксиса языка выглядит реверансом в сторону прикладной семантики. Что является во-первых переусложнением, во-вторых слишком неоправданно за счёт узкой специфики применения, ну и в-третьих является большим препятствием для мультитаргетности - SQL-сервер вряд ли будет непременным атрибутом микроконтроллера; а стандарт языка - требует; это похоже на привязку старинного TurboPascal к PC-шной консоли - непременно 80x25 и непременно 16 цветов. В эпоху ДОС такое прокатило, сегодня это неактуально. Более того, если пойти дальше, то следует включить в язык и регулярные выражения, и работу с XML, и поддержку различных кодировок текста, и меры длины и веса, и многозадачность и ещё очень и очень многое. Получим монстра, обладающего ещё одним недостатком, помимо сложности - это будет реализация многозадачности только одним способом. Работа с регулярными выражениями - только одним способом. И так далее. Ну а расширяемые языки на практике не обладают рёбрами жёсткости - на том же Форте можно писать так, что без знания специфики словарей в коде не разберёшься.

Впрочем, Обероны присматриваются к расширяемости. В ETH Oberon, например, есть перегрузка операторов. Поэтому встроить конкатенацию привычным способом - можно. И лямбды наверное тоже, просто я не пробовал. :)

Так что я за некоторую жёсткость в противовес излишней расширяемости всё-таки. Оно надёжнее как-то. Так что Оберон вполне себе в своей нише, где, кстати, живёт и Google Go, похоже.

Интерпретатор Оберона на Go (http://habrahabr.ru/post/252677/). Познавательно.

Vitamin

06.10.2015, 23:36

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

Oleg N. Cher

07.10.2015, 00:44

Ну да, пишут мегасистемы. Там, где считают нужным, в своей нише. Умные люди притом. Vitamin, а где это я говорил о "я вот тоже написал очередную мегасистему"? Ткни. Иначе твой наезд гнилее некуда.

---------- Post added at 00:44 ---------- Previous post was at 00:27 ----------

Я, напротив, везде говорю о том, что XDev по максимуму собран из готовых компонентов - Ofront'а, BlackBox, SDCC и т.д. Которые написал, разумеется, не я. Просто скомпоновал.

s_kosorev

07.10.2015, 00:48

И вот с этой позиции, которую я горячо поддерживаю, внедрение SQL прям на уровне синтаксиса языка выглядит реверансом в сторону прикладной семантики.
в C# linq это не встроенная в язык фича, это реализовано библиотекой, хоть из набора стандартно поставляемых, используется конечно много технологий, что бы выглядело все это дело более менее как SQL, но тем не менее, всего лишь библиотека. Ну и VS умеет подсвечивать.

X++ же, это часть ERP системы, она только на компьютерах работает

Vitamin

07.10.2015, 08:07

а где это я говорил о "я вот тоже написал очередную мегасистему"? Ткни. Иначе твой наезд гнилее некуда.
В названии темы. Первое слово и капс. Если капс - это объективная информация (языки можно перечислить), то прилагательное "мощная" - чистая субъективность.

Oleg N. Cher

07.10.2015, 21:56

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

Ну пишут на Обероне системы. Ну есть у этого языка достоинства. Хотя тебе не понять, просто потому что ты наёмник. А на разум наёмного рабочего наслаивается его профессиональное выживание, стимулирующее его к освоению новых высот - иначе выпадет из профессии. Для тебя хорошо то, что тебе позволяет прокормиться. Но и C# из профессии выпадет, покроется молью и пылью. Не угонишься за всем этим. Но ведь если простота - достоинство, а это во многих случаях так, тогда у Оберона есть преимущество перед C# и C++. Если мультитаргетность достоинство - у Оберона снова есть преимущество перед C#, несмотря на микродотнет. Так что пишут на Обероне, хоть что ты делай. Такие как я. Ну не нужны мне ленивые вычисления, простоты хочу. :) Хочу главного - возможности своими корявыми ручонками и малопроизводительным мозгом (см. Дейкстру - Смиренный программист) влиять на развитие языка (https://code.google.com/p/ofront/issues/detail?id=5). И чтобы исполнить это - мне нужно брать или недоязык-поделку, или Оберон, за которым всё-таки солидная академическая база и хоть какое-то коммьюнити.

Vitamin

07.10.2015, 22:27

Vitamin, я имею право называть тему как бы не спрашивая твоего мнения.
Разумеется. Я разве где-то сказал обратное?

Но то, что ты прощаешь себе - мне простить не в силах.
Что именно? С примерами, пожалста...

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

И чтобы исполнить это - мне нужно брать или недоязык-поделку, или Оберон, за которым всё-таки солидная академическая база и хоть какое-то коммьюнити.
Как ты сам говоришь, небольшое коммьюнити. Возможно, этому причина как раз "академичность" языка. Ибо:

Есть всего два типа языков программирования: те, на которые люди всё время ругаются, и те, которые никто не использует.

s_kosorev

07.10.2015, 22:38

Если мультитаргетность достоинство - у Оберона снова есть преимущество перед C#, несмотря на микродотнет.
Может и есть только не понятно где, собранных C# dll и даже exe без перекомпиляции может работать, (WinPhone/IOS/Android) (Win/MacOS/Linux) (X86/X64/Arm) куда уже мультитаргетнее, оберон если я не ошибаюсь, нет даже нативных компиляторов для X64

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

Oleg N. Cher

07.10.2015, 23:22

s_kosorev, BlackBox'овский скомпилированный модуль в формате .ocf имеет секции под различные процессоры. Это конечно задел на будущее, но вот где-то припрятала фирма Oberon Microsystems в своих недрах компиляторы под Motorola 680x0 и даже в байт-код JVM. Такая фигня - самые интересные разработки на Обероне обычно закрыты. Другие открытые, но малоизвестны. Вот вы знали, что есть реализация JVM для AO - Jaos (http://www.ethoberon.ethz.ch/jaos/index.html)?

А на сегодняшний день кодовые модули .ocf (Oberon Code File) без перекомпиляции работают как в Windows, так и в Linux на архитектуре x86-32, притом даже не требуя виртуальной машины.

Собсно оберонщики - люди хитрые. На WinDev можно программить под X64, правда, не совсем честно - через Си. Но есть и нативный компилер Оберона-07 для X64 - AyaCompiler, ссылку я давал выше.

---------- Post added at 23:13 ---------- Previous post was at 23:00 ----------

А плоские бинарники (slim binaries) - это вообще платформенно-нейтральное представление, которое транслируется в код конкретной архитектуры динамическим кодогенерирующим загрузчиком. Виртуальная машина (aka эмулятор байт-кода Y для платформы X) абсолютно не требуется. Очень прогрессивно, не находите? См. диссертацию Микаэля Франца "Динамическая кодогенерация: ключ к разработке переносимого программного обеспечения (http://zx.oberon2.ru/forum/viewtopic.php?f=3&t=147)". И это также рождено в Оберон-парадигме.

---------- Post added at 23:22 ---------- Previous post was at 23:13 ----------

Я в своё время комментировал это "достоинство" .NET

Мне кажется, Францем предложен более совершенный способ трансляции, который решает, в основном, все проблемы, присущие VM. Перечислю их вкратце.

Более экономичное использование памяти (нету VM).

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

Кодогенерирующий загрузчик может на лету оптимизировать код для установленного процессора. Т.е. одна программа на Slim Binaries будет оттранслирована максимально эффективно в код i386, и также в код PIII с архитектурой IA64. Это всё достигается и с помощью JIT-компиляции (в .NET и JVM), но значительно более дорогой ценой. Высокие показатели оптимальности кода на тестовых испытаниях оборачиваются на практике реальнейшим кошмаром. VM жрут сотни мегабайт памяти оверхеда по сравнению с нативом, а софт неслабо тормозит, в сравнении с аналогичным, но статически слинкованным в натив. Если бы не было современных процессоров, он бы вообще не работал. Но если для десктопов это ещё как-то терпят (ибо высокий штандарт давно и накрепко задан мелким и мягким большим сэмом), то на планшетах у них, видать, тормозит. Меня ещё тогда порадовало, что Dalvik регистровый. Ведь ежу понятно, что стековая VM ещё тормознее, и не только на процессорах архитектуры ARM.
Никак не могу углубленно прокомментировать это, но у меня подход с VM вызвал отторжение с того самого дня, как я о нём узнал. И нынче приемлю их только в эмуляторах других платформ. Там это неизбежность. А вот подход Франца сразу же поразил в плане совершенства. И я рассказывал о нём мэйнстримщикам, самые умные из которых сказали: "ну подождём, что из этого выйдет".

s_kosorev

07.10.2015, 23:31

притом даже не требуя виртуальной машины
C# не виртуальная машина, если что, он сразу пошел по другому пути, не предоставляя виртуальную среду, собсно из за этого переносимость ниже, производительность выше.

самые интересные разработки на Обероне обычно закрыты.
на закрытые технологии опасно полагаться

JVM для AO - Jaos?
JVM есть куда угодно, в том числе и под чистые процессоры без ОС, этого ява добивалась и добилась

это вообще платформенно-нейтральное представление, которое транслируется в код конкретной архитектуры динамическим кодогенерирующим загрузчиком
ну так оно также C#, Java, LLVM

Oleg N. Cher

08.10.2015, 00:06

Не, разница всё-таки есть, поверьте. Или разберитесь. Дисер прочтите, например. Или сходите по ссылке выше, почитайте что я отвечал по этому поводу geniepro.

C# - это язык-платформа, иначе не будет плюшек в виде мета-средств и т.д. Притом реализовано всё поверх железа достаточно толсто и сложно.

s_kosorev

08.10.2015, 00:31

Не, разница всё-таки есть, поверьте. Или разберитесь.
несколько милисекунд на запуск? вообще llvm почти сразу в бинарный код переводится под конкретную платформу, java не специалист в .net есть ngen который может вызывать инсталятор, так что разницы нет, разные подходы

---------- Post added at 00:31 ---------- Previous post was at 00:29 ----------

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

msm

08.10.2015, 09:46

Error404

08.10.2015, 10:11

оптимизации ограничены только крутостью разработчиков.

с этим и проблема.
по крайней мере пока что была

jerri

08.10.2015, 15:56

Хм. Интересно почему SDCC умудряется уступать древнющему HiTech C? Или просто проигрывает по плотности, выигрывает по производительности? Я что то сильно сомневаюсь, что в HiTech C делали какие то оптимизации, там наверняка компилятор простой как пробка. На оптимизацию не хватит ни ресурсов процессора, ни памяти. А SDCC то по ресурсам практически никак не ограничен, соответственно оптимизации ограничены только крутостью разработчиков.

потому что эти авторы HiTech C писали программы под весьма хилые машинки и надо было соблюдать баланс скорость/качество и следить за размером. HiTech C, как говорят, написан на С

SDCC написан на очень мощном компе, людьми которые не привыкли экономить. вот и весь сказ.

msm

08.10.2015, 21:44

Следить за размерами чего? Авторам HitTech C нужно было следить за размерами в первыю очередь компилятора. А когда приходится следить за размерами, там не до оптимизаций, там тупо делать просто как пробка и все. А когда компилятор работает на мощной машине, можно там хоть террабайт ресурсов выделить, но кодогенерацию при этом сделать вообще идеальной.

Error404

08.10.2015, 22:05

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

jerri

08.10.2015, 22:13

Oleg N. Cher

08.10.2015, 22:38

s_kosorev, спектр разброса наших тем общения маленько выходит за мои возможности. То же самое скажу и Vitamin'у, хотя он будет как всегда недоволен, и скажет, что я съезжаю. Если не видите разницы между .NET и подходом со slim binaries - пусть будет так, вам виднее.

А вообще давайте не ругаться, давайте лучше библиотеки делать. :) Можно сразу под главные сишные компилеры.

P.S. Если болдердаш всё-таки доживёт до релиза - я обязательно соберу его как минимум тремя компилерами - Hitech C, IAR C и z88dk, только мне понадобятся консультации знатоков тонкостей этих компилеров.

s_kosorev

08.10.2015, 22:48

Если не видите разницы между .NET и подходом со slim binarie
подход может быть какой угодно, смысл в том что практической разницы нет, даже в случае прекомпиляции инсталером, слимы проигрывают

Oleg N. Cher

08.10.2015, 22:57

Почему же? :)

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

---------- Post added at 22:57 ---------- Previous post was at 22:55 ----------

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

s_kosorev

08.10.2015, 23:06

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

Oleg N. Cher

08.10.2015, 23:08

Понятно. Ну я не дока в дотнете - просто в диспетчере процессов смотрю на эту каку и ругаюсь ;)

s_kosorev

08.10.2015, 23:09

Да, эта балда по имени дотнет ещё и несовместима сама с собой ни сверху вниз, ни снизу вверх, и если у вас две проги в памяти требуют разных версий дотнета - будьте уверены, что одновременно загруженные две версии рантайма жрут ещё больше памяти.
Это правило действует только для .net 1.1 против других, остальные совместимые и рантайм один, не надо заливать, версии библиотек могут быть загружены куча, это да, но тут опять же от непонимания, у .net есть привязка к версии библиотеки, это метод устранения dll hell

Oleg N. Cher

08.10.2015, 23:11

Это метод не только борьбы с dll hell, но и с любым объёмом имеющейся памяти ;)

s_kosorev

08.10.2015, 23:11

Понятно. Ну я не дока в дотнете - просто в диспетчере процессов смотрю на эту каку и ругаюсь
тебе какая разница, как используется незадействованная память?

Oleg N. Cher

08.10.2015, 23:13

Положим, у меня две проги запущены, юзающие разные версии дотнета, докучи ещё Java-приложение, пара эмуляторов, офис и несколько окон браузера. С точки зрения юзера это удобно, а с точки зрения экономии памяти - это варварство. Каждая прилада резервирует под себя кучу места, JVM и .NET готовы сожрать друг друга. В линуксе такой же ад. Вот я и думаю - куда (it-) мир катится ;)

s_kosorev

08.10.2015, 23:14

Это метод не только борьбы с dll hell, но и с любым объёмом имеющейся памяти
код занимает на самом деле мало места, да и это вопрос надежности, приложение тестируется и публикуется в определенном кодовом окружении, .net позволяет воссоздать это окружение, если приложение не привязано в минорной версии, то они будут одну и туже библиотеку использовать

Oleg N. Cher

08.10.2015, 23:15

Я же не спорю, всё это варварство абсолютно оправдано и предельно отточено. Но есть и 20-килобайтный Hitech C, который сделал полуторамеговый SDCC ;)

s_kosorev

08.10.2015, 23:22

Положим, у меня две проги запущены, юзающие разные версии дотнета
.net 3.5 это 2.0 + доп либы, дотнет 4.0 это 3.5 + доплибы итд
у 4 и 2 разные рантаймы, но рантайм 4 версии умеет запускать 2 версию, так что тоже байки

---------- Post added at 23:22 ---------- Previous post was at 23:16 ----------

Но есть и 20-килобайтный Hitech C, который сделал полуторамеговый SDCC
кто нить показал бы сравнения ассемблера обоих компиляторов на какой нить более менее сложной процедурке, есть подозрение что hitech C код может из одних call состоять, вызывать предопределенные процедуры из rtl, код будеть меньше но и гораздо тормознее.

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

Vitamin

09.10.2015, 12:13

Hitech C, IAR C и z88dk, только мне понадобятся консультации знатоков тонкостей этих компилеров.
Не знаток, но давным-давно делал тестирование кодогенерации (http://zx-pk.ru/showthread.php?t=4110&page=7#68) этих и нескольких других компиляторов. С тех пор что-то могло поменяться, все же 9 лет прошло...

Понятно. Ну я не дока в дотнете - просто в диспетчере процессов смотрю на эту каку и ругаюсь
А в какую колонку диспетчера памяти ты смотрел? А то там аж 7 показателей памяти для разных целей имеется.

Каждая прилада резервирует под себя кучу места, JVM и .NET готовы сожрать друг друга. В линуксе такой же ад. Вот я и думаю - куда (it-) мир катится
Какие альтернативы? Разумеется, кроме "переписать все на обероне".

Oleg N. Cher, ты смотришь на результаты разработки на С#/Java как пользователь (что логично), но выводы делаешь как программист, не желая вникать в детали. Это все равно что я попробую твою среду и скажу: "Оберон - это полная хрень, компилятора нет - все к С преобразуется, а после этого еще смеет рассуждать об оптимальности его использования на спеке".

Oleg N. Cher

09.10.2015, 16:49

Использовать Оберон для разработки под Спектрум неэффективно.

Похоже, что самым лучшим ЯВУ (и переносимым ассемблером) для процев типа Z80 была бы Модула-2. Объединения. Беззнаковые типы. Только компилятор нужен очень хороший, оптимизирующий, а такого для Z80 нет, есть только Mira Modula нативная.

SaNchez

09.10.2015, 18:16

Неееет..:v2_crazy:
Дружище, не торопись, сядь и спокойно во всём разберись. (с) pr-mex
imho, для разработки на спектрум любой ЯВУ использовать не эффективно.

Error404

09.10.2015, 21:24

Похоже, что самым лучшим ЯВУ (и переносимым ассемблером) для процев типа Z80 была бы Модула-2. Объединения. Беззнаковые типы. Только компилятор нужен очень хороший, оптимизирующий, а такого для Z80 нет, есть только Mira Modula нативная.

Не только. :)
http://techtinkering.com/2013/03/12/if-only-borland-had-stuck-with-turbo-modula-2-for-cpm/

Andrew771

10.10.2015, 14:40

imho, для разработки на спектрум любой ЯВУ использовать не эффективно.
Смотря что писать. Пошаговки, квесты, логика и двумерные лабиринты можно на ЯВУ.

Oleg N. Cher

11.10.2015, 13:20

Ответственно заявляю, господа, что я окончательно решил забить на идею превратить Оберон в Модулу-2 добавлением беззнаковых типов и т.п. CP/M-ная Модула конечно хорошо, но наверное лучше будет найти транслятор Модулы-2 в Си и пойти стопами ZXDev. Но это для гурманов. Я же решил выпилить рудиментарную поддержку беззнаковых типов в Ofront'е (они всё равно глючат) и перевести ZXDev в статус исследовательского проекта. Вы же уже убедились, что своими скромными силами сделать продвинутые библиотеки я не смогу. Также забиваю на юзеров ZXDev, их всё равно нет, продолжу проект чисто для себя.

Screw

11.10.2015, 22:07

Я же решил выпилить рудиментарную поддержку беззнаковых типов в Ofront'е (они всё равно глючат)

Вот это поворот! Прогрессивнейший, мощнейший язык и тут такой прокол...

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

Тем более чудесен факт создания этой мощной среды. Не отчаивайтесь.

Oleg N. Cher

15.10.2015, 00:28

Какой смысл превращать Оберон в Модулу, ведь это всё равно не Си, на котором можно писать как на асме. На ZX ниша Оберона такова - ни больше, ни меньше:

Cи на спеке полезен для общей организации кода -- на нем хорошо писать этакий фреймворк, который вызывает ассемблерные процедуры (для такого, вобщем-то, хоть бейсик можно юзать) -- ресурсы не критичны, зато код легко структурировать. пример: z88dk+spritepack, на которых, насколько понимаю, писаны phantomasa и еще кое-чего из последнего (при всей неоптимальности пусть и ассемблерного spritepack, который построен по слишком обобщенной архитектуре, чтоб эффективно юзать ресурсы, игрулька вполне играбельная )

Andrew771

29.10.2015, 23:01

Сообщение от Andrew771
А ты пробовал сравнивать на реальных примерах? Я пробовал SDCC, как увидел регистр IY, поплохело.
А не пробовал поиграться опциями компиляции? --opt-code-size, --opt-code-speed, --reserve-regs-iy, --oldralloc и другими?

Цитата:
Сообщение от Andrew771
Ты дай коротких примерчиков на Обероне для тестинга. Просто интересно сравнить качество кодогенерации.
Примерчики есть в поставке, я не знаю, что ты имеешь в виду. Или давай напиши их на ZX-like Pascal, а я перепишу на Оберон.
Взял в твоем дистрибутиве демо-программу Kubik и переписал на Паскале. Выкладываю обе в архиве: исходники, асмы и скомпилированные в ZXDev и ZX Like Pascal, сравниваем.

jerri

30.10.2015, 09:36

Andrew771, чота как то неравномерно.
там просто считалка с простым выводом
а тут и на скорость наворочено и фонт добавлен на 64.

Andrew771

30.10.2015, 09:47

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

Oleg N. Cher

02.11.2015, 04:02

Этот Kubik построен на выводе, реализованном в библиотеке Basic (исходник лежит в ZXDev/Lib/C/Basic.c). По умолчанию используется стандартный вывод (RST #10) - для экономии памяти. Чтобы увеличить скорость вывода, закомментируем в ZXDev/Lib/BasicCfg.h:

//#define ROM_OUTPUT

( каждый модуль, не использующий общий конфигуратор, может иметь свой собственный - в папке Obj/ИмяМодуля )

Теперь достаточно пересобрать (F12).

Отчасти заметил, что ZX-like Pascal иногда даёт более эффективный код, чем SDCC, и с этим не собираюсь спорить. Браво.

Вывод разными шрифтами я не реализовал, как-то не понадобилось.

Andrew771

02.11.2015, 16:54

Кстати, в этой программе kubik неэффективно сделан вывод на экран, зачем-то каждая строка выводится отдельными операторами. Можно было в цикле. Но зато выявилось преимущество SDCC - он не повторяет в данных одинаковые строки, а ZX Like повторяет. В общем, доработаю это у себя.

Sergey

02.11.2015, 19:53

Oleg N. Cher

03.11.2015, 00:32

Kubik написан (под моим руководством конечно) моей племянницей, отсюда неоптимальности.

Андрей, чтобы не было вот такого:

ld hl,0
ld (_ONE),hl
ld hl,0
ld (_TWO),hl
ld hl,0
ld (_THREE),hlсоветую сделать “слово состояния процессора (http://zx-pk.ru/showpost.php?p=541816&postcount=85)”. И вот ещё идеи по оптимизации (http://zx-pk.ru/showpost.php?p=542345&postcount=96).

Sergey

03.11.2015, 04:48

... ещё идеи по оптимизации.
Ну что, Олег, - навостряй лыжи прикручивать к ZXDev ZX Like Pascal ;)

Oleg N. Cher

03.11.2015, 06:41

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

Замечу, что в SDCC реализованы более сложные оптимизации, чем в ZX-Like Pascal.

Sergey, накопились вопросы по HiTech C, если можно.

Не нашёл откуда качать HiTech C v3.09 для DOS.
Есть ли какие-либо преимущества от использования DOS-версии перед CP/M-версией? (например, можно ли задавать пути? - ведь в CP/M нет каталогов и всё должно быть свалено в одну кучу).
Тестировались ли более свежие (хоть и платные) версии HiTech C для Z80? (у них может быть ещё более качественный кодогенератор).

Sergey

03.11.2015, 11:58

Не нашёл откуда качать HiTech C v3.09 для DOS.

Забудь, версии под дос не существует.

Есть ли какие-либо преимущества от использования DOS-версии перед CP/M-версией? (например, можно ли задавать пути? - ведь в CP/M нет каталогов и всё должно быть свалено в одну кучу).

Ввиду отсутствия первой - никаких. Да, в в CP/M я храню исходные тексты на одном диске с дистрибутивом HiTechC. Скорее всего, можно разнести на разные "диски" - не пробовал пока. Можно скриптами перед компиляцией копировать к файлам проекта эмулятор CP/M и необходимые cp/m-программы и др.файлы, а после компиляции - удалять их.

Тестировались ли более свежие (хоть и платные) версии HiTech C для Z80? (у них может быть ещё более качественный кодогенератор).
Я не тестировал, т.к. ничего недоступно.

Alcoholics Anonymous

09.11.2015, 03:51

Замечу, что в SDCC реализованы более сложные оптимизации, чем в ZX-Like Pascal.

Глазок оптимизатор, который поставляется с SDCC является достаточно мощным и может быть использован для улучшения вывода SDCC в значительно.

SDCC имеет ряд недостатков: он не может справиться с статика, длинных или плавает эффективно. Статика особенно важно, потому что лучшее исполнение Z80 происходит от их использования в предпочтении к локальным переменным, когда разумно. Но это не случай с SDCC - использование статики приводит к плохой код. Во всяком случае, эти проблемы могут быть решены с помощью щелевого оптимизатора, и мы делали, что в z88dk. Если вы используете SDCC через z88dk качество кода гораздо лучше.

Другая проблема SDCC имеет это относится к z80 как чистый 8-битный процессор и, в основном игнорирует свои 16-битные инструкции. Опять мы можем попытаться исправить, что в peepholer но мы не всегда можем это сделать. SDCC иногда меняет порядок байт в коде, который не легко исправить.

Посмотрите на состояние вещей в настоящее время при использовании SDCC через z88dk:

https://drive.google.com/file/d/0B6XhJJ33xpOWcUJDUVlQdkNtdk0/view?usp=sharing

Эта программа вычисляет пи до 800 знаков после запятой, и мы используем его для сравнения 32-битной целочисленной арифметики. Оба выходной файл ASM были составлены с использованием SDCC z88dk библиотеки. "пи-sdcc.opt" код, который генерирует SDCC сам по себе. "пи-z88dk.opt" это код после z88dk применяет свои правила, чтобы улучшить его. Это гораздо лучше, и это почти все из щелевого оптимизатора SDCC в.

Кроме стороне генерации кода, нет никакой другой компилятор Z80 С, что делает столько оптимизации в переднем конце. Это только генерацию кода и библиотек (написанный на C), которые весом вниз SDCC.

The peephole optimizer that comes with sdcc is quite powerful and can be used to improve sdcc's output considerably.

sdcc has a number of weaknesses: it can't deal with statics, longs or floats efficiently. Statics are especially important because the best z80 performance comes from using them in preference to local variables when reasonable. But that's not the case with sdcc -- use of statics leads to poor code. Anyway, these problems can be fixed by the peephole optimizer and we've been doing that in z88dk. If you use sdcc through z88dk the code quality is much better.

The other problem sdcc has is it treats the z80 like a pure 8-bit processor and mostly ignores its 16-bit instructions. Again we can try to fix that in the peepholer but we can't always do that. sdcc sometimes swaps endianness in code which is not easy to fix.

Have a look at the state of things now when using sdcc through z88dk:

https://drive.google.com/file/d/0B6XhJJ33xpOWcUJDUVlQdkNtdk0/view?usp=sharing

This program computes pi to 800 decimal places and we use it to benchmark 32-bit integer arithmetic. Both asm output file were compiled with sdcc using the z88dk libraries. "pi-sdcc.opt" is the code that sdcc generates by itself. "pi-z88dk.opt" is the code after z88dk applies its rules to improve it. It's much better and this is almost all due to sdcc's peephole optimizer.

Apart from the code generation side, there is no other z80 C compiler that is doing as much optimization in the front-end. It's just the code generation and libraries (written in C) that are weighing down sdcc.

Sergey, накопились вопросы по HiTech C, если можно.

Не нашёл откуда качать HiTech C v3.09 для DOS.

Hitech С v3.09 еще, кажется, отстают в бенчмаркинга:
http://www.z88dk.org/wiki/doku.php?id=temp:front#dhrystone_2.1

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

Hitech C v3.09 still seems to fall behind in benchmarking:
http://www.z88dk.org/wiki/doku.php?id=temp:front#dhrystone_2.1

There was a later version v7 for dos but I cannot find it and it's no longer being sold as far as I know.

Andrew771

07.12.2015, 15:55

я предпочитаю открытый софт - его легче сопровождать и дорабатывать.
Исходник ZX Like Pascal положил тут (http://zx-pk.ru/showthread.php?t=54&page=14&p=810433&viewfull=1#post810433)

Smalovsky

08.12.2015, 13:23

Чем Компонентный Паскаль отличается от Оберона-2?

Oleg N. Cher

09.12.2015, 04:56

КП позиционируется как диалект (фактически надмножество) Оберона-2 для промышленного применения. Прикладному программисту КП покажется более удобным и фичастым. Некоторые приятные мелочи, как: IN/OUT параметры процедур, расширенная работа с битами. Главная фича КП, отсутствующая в О2, - реализация абстрактных интерфейсов.

http://www.inr.ac.ru/~info21/info/qtocompascal.htmhttp://oberoncore.ru/wiki/lang/component_pascalhttp://www.sbup.com/wiki/Компонентный_Паскаль (http://www.sbup.com/wiki/%D0%9A%D0%BE%D0%BC%D0%BF%D0%BE%D0%BD%D0%B5%D0%BD%D 1%82%D0%BD%D1%8B%D0%B9_%D0%9F%D0%B0%D1%81%D0%BA%D0 %B0%D0%BB%D1%8C)

Основные уточнения Компонентного Паскаля по сравнению с Обероном-2 касаются следующего:

Главная идея уточнений по сравнению с Обероном-2 была в том, чтобы дать проектировщику компонентного каркаса (т.е. интерфейсов модулей, определяющих абстрактные классы для конкретной проблемной области) более полный контроль над её проектируемыми свойствами в плане безопасности. Введены специальные атрибуты для типов (ABSTRACT, EXTENSIBLE, LIMITED) и методов (ABSTRACT, EMPTY, EXTENSIBLE), позволяя автору программной компоненты (группы модулей) осуществлять контроль в плане того, разрешать или нет модулям-клиентам расширять предлагаемые им типы.

Модернизирована несколько устаревшая система основных типов Оберона: теперь набор основных типов Компонентного Паскаля является надмножеством для основных типов языка Java. Основные «рабочие» типы INTEGER, REAL и CHAR соответствуют 32-, 64- (т. н. двойная точность) и 16-(Unicode)-битовым переменным, что позволяет уменьшить разнообразие основных типов, реально используемых в большинстве случаев; использование других типов (LONGINT, SHORTREAL, SHORTCHAR и т. д.) ограничивается специальными приложениями.

Добавлены базовые средства для работы с цепочками литер (неявный тип String), что вместе со стандартным модулем Strings в системе программирования BlackBox делает Компонентный Паскаль более удобным, чем Паскаль или Оберон, для работы со строками. Цепочки литер представляются массивами литер (ARRAY OF CHAR или ARRAY OF SHORTCHAR), причем значением считается последовательность литер до первого вхождения специальной литеры-ограничителя 0X. Цепочки литер можно сравнивать (подразумевается лексикографическое сравнение) и складывать (конкатенация). Конструкция a := b$ позволяет скопировать в массив литер a цепочку, хранящуюся в массиве литер b (включая литеру-ограничитель 0X), даже если присваивание a := b запрещено (например, из-за разной длины массивов a и b).
Полное описание синтаксиса языка в расширенной форме Бэкуса-Наура приведено на страницах Сообщения о языке Компонентный Паскаль. Оно содержит 34 грамматических выражения, что лишь на одно больше чем для Oberon-2.

Имеется 2 реализации КП: BlackBox Component Builder (Windows/Linux) и GPCP (.NET/JVM). Последний ещё более расширен: добавлена обработка исключений, новые типы и т.д. Также в XDev реализованы некоторые возможности языка КП.

Рекомендую относиться к О2/КП как к "ассемблеру ООП", т.е. с точки зрения фичь они проигрывают C#/Java. Среды разработки на О, О2, AO, КП - чаще всего не классические IDE + отладчик (хотя встречаются и такие), и с этой точки зрения тоже проигрывают.

А ещё есть Модула-2 и Модула-3. Тоже хорошие языки. Даже несколько больше и фичастее Оберона, но намного меньше Ada/C++.

Исходник ZX Like Pascal положил тут (http://zx-pk.ru/showthread.php?t=54&page=14&p=810433&viewfull=1#post810433)Андрей, благодарю, что ты решился.

Практика показывает, что страх потерять контроль над разработкой, открыв исходники, - неоправдан. Честно. Взамест проект может приобрести более конструктивную и качественную критику (уже на основе взгляда на код), новых участников и новую жизнь. А может и не приобрести. Как повезёт. У наший с тобой проектов потенциальная аудитория маловата, увы. Мои самые лучшие юзеры, как правило, уходили непонятно куда. Вот и Руслан (http://zx-pk.ru/member.php?u=3220) в теме испрашивал что-то вроде лазер бейсик (http://zx-pk.ru/showthread.php?t=17307&highlight=), а что может быть ближе к Laser Basic, чем ZXDev + библиотека Laser? Я ему даже засмартлинковал (http://zx.oberon2.ru/forum/viewtopic.php?f=10&t=190#p1252) (порезал на части) библиотеку Laser, потратил на это несколько дней. Очень кропотливая работа. Хотя по-честному его целиком переписывать надо. С учётом новых достижений кодерской мысли. Но то мечты, а это уже реальная отлаженная библиотека. Но, упс, получается, зря делал.