OberonCore

Если кратко, то в языке должна быть конструкция USING, позволяющая подключать модули поддержки синтаксиса. Это означает расширяемость компилятора (во время компиляции), а не его доработку.

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

Язык с динамически мутирующим синтаксисом... ООП отдыхает, это точно. Не говоря уже о С++ с его жалкими перегрузками и #include.

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

Непонятно - что этот код делает. Из-за того, что полет фантазии автора не ограничен даже синтаксисом.



Эту мысль я не понял.

Фантазия конечно разная, но от синтаксиса наяву никто вроде не отказывается. Что касается последнего - то там две разные мысли. Если серьезно, то логика такова: модули, перекрывающие функции друг друга не способствуют экономии памяти. А вы что хотели понять?

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

"Мутация" - это что болезненное, а "эволюционное развитие объекта", как в биологии, фундамент к адаптации и выживанию в любой самой агрессивной среде.

Но имеется ли язык с обозначенными свойствами? Есть - это ФОРТ (Forth). Да трудный. Трудно освоить, трудно понять парадигму и приобрести навыки.

Вот один из последних красивых решений. Расширяемый язык http://forpost.sourceforge.net/ (Скачал и попробовал. Обязательно перепишу для Modula-2. Есть же красота в мире программных средств!)

ЦИТАТА:

(Пётр Советов)

Вступление
Описание языка
Особенности реализации на Си
Справочник по словам ядра

Вступление

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

Объем исходных на 'С' и исполнительных файлов forpost-051110.zip=49262 байт !

Теперь о тех инструментах которые мы любим. Чего не хватает? Именно модуля описания грамматики G. При наличии описания грамматики диалектов языков, плюс некоторые правила миграции на другие языки - трансляция и перевод программ станет действительно тривиальной задачей для конкретной парадигмы программирования.

Чтобы мы не писали на HI или LOW языках -- конечный итог машинный код для процессора x86 (в основном)...

Верно, господа программисты?

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

Есть много примеров абсолютно гибких, "амебных" языков, "основанных всего на нескольких общих и ясных правилах". Тот же LISP - казалось бы, что проще - и программа, и данные выглядят одинаково - списки. Изучить сам язык действительно ничего не стоит, но вот понять, как его применить к реальной задаче, во много раз сложнее. И научиться писать на LISP не легче, чем на C++. А на практике? В конце концов все равно вводят эмуляцию "нормальных" языков, получая нечто неудобоворимое и плюющееся ошибками (пробовал одну очень дорогую коммерческую версию того же LISP, который пытался подражать Delphi и VCL)

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

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

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

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

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

А если поставить самое последнее требование - пригодность для компонентного ПО с динамическим связыванием, то остается вообще три-четыре полноценных конкурента. Мне на ум приходят (в порядке их рождения) Java, Component Pascal и C#. Даже такие гиганты, как С++, Ada, Eiffel в последнюю категорию не попадают.

Вот мы и избигаем крайности. Берём что есть на рынке раскрученное и известное "строим приложения". В своём выступлении Вирт высказал мысль:" Нужно студентов учить не языку программирования, а программированию!" Опять нужно искать красивые решения в области математики и абстракций.

Покажу на примере метода вычисления мат. функций способом "цифра за цифрой". Если бы не качественная проработка математиков, спали бы мы у мониторов дожидаясь решения уравнений. Один из авторов ("Система счисления с основанием кода Фибоначи", Стахов А.П.) получил патенты на цифровые микросхемы, которые работат с основание {0,1,2}. Зачем? Есть же классика {0,1}. Но именно базовая смена основания позволила создать совершенно новые качественные свойства элементов. Из его работ по цифро-аналоговой техники следует, что при переходе на числа Фибоначи точность измерений увелилась на порядки (!!), уменьшились шумы, микросхемы могли самодиагностировать все (!) этапы вычислений и преобразований. Кстати, в современных процессорах x86 всё это реализовано. Там есть модуль, который как раз использует свойства чисел Фибоначи для контроля достоверного выполненных операций. Т.е. есть один единственный выход {0 или 1} - контроль правильности выполнения любой операции на уровне процессора.

1. Азаров А.Д. К вопросу об оценке надежности преобразователей информации на основе кодов с иррациональными основаниями // Методы построения алгоритмических моделей сложных систем. Выпуск 4. -Таганрог: ТРТИ, 1979.- С. 146-149.

2. Стахов А.П., Азаров А.Д., Рубин А.Г. О возможности создания надежных преобразователей информации на основе кодов с иррациональными основаниями // Управляющие системы и машины.- 1980.- №4.- С. 49-53.

3. Высокоточный самокорректирующийся аналого-цифровой преобразователь на основе кодов с иррациональными основаниями / А.П. Стахов, А.Д. Азаров, В.И. Моисеев и др.- Киев: ИК АН УССР, 1982.-35с.

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

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

В этой ветке самая сильная идея, еще раз процетирую,


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

1)

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

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

3) Компонентное ПО и модульное ПО предполагает как раз-таки жесткость, стандартизированность языковых средств. Именно потому в линейке Java-ComPascal-C# убрано или ограничено обобщенное программирование и перегрузка - они не могут работать между компонентами, т.к. требуют исходных кодов и перекомпиляции.

4) Для динамически мутирующего синтаксиса требуется интерпретатор. Интерпретатор в промышленности неконкурентоспособен.
Особенно если учесть, что хорошая среда для ЯП должна быть написана на самом языке и собрана сама в себе (Как сказал Пфистер: первая проверка качества языка и среды - в том, что она должна быть сделана на самой себе, "врач должен пить собственные лекарства").
В противном случае я не понимаю слова "динамически" - в компилируемых языках в "run-time" и мутировать-то нечему - синтаксиса уже нет, есть черные ящики - компоненты и бинарным интерфейсом.

5)
Подчеркну еще раз:Качественные характеристики для "программирования в малом" у большинства современных языков сравнялись. И тут никакие мутации синтаксиса не актуальны.
Важно то, как язык позволяет выражать проектные решения, описывать правила взаимодействия (динамически связываемых) компонентов в больших системах. И вся гибкость языков прошлого поколения типа Форта уже никому не нужна, если они не поддерживают мощную систему абстраций данных и не позволяют непосредственно выстраивать архитектуру системы.

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

Здесь есть несколько сложностей в части выбора в массах компонентного ПО.

а) Большие проекты уже созданы на других языках программирования: С, С++. Например, MS OS WinXX, OS Linux, OS Unix, OS BeOS и мн. другие.

б) У интернет сообщества языки PHP, Perl. О чистой Java ничего не могу сказать. Но как пользователь могу сказать - медленно в стандартной поставке. Нужно проделать много чего, чтобы производительность приблизилась к приложениям, созданным на стандарных компиляторах. Прижилась JavaScript. Но какую долю занимает код на скрипте к обычному HTML?

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

Мне нравится реализация TEXT в BlackBox. Хочется перенести редактор на один из диалектов MODULA-2. Спрашиваю Вас:"Это возможно?"

Хочется узнать ваше мнение о таком проекте:
http://www.gentee.ru/doc/syntax/index.htm

ЦИТАТА:
"Введение
Язык программирования Gentee является процедурным языком высокого уровня. Синтаксис языка имеет много общего с синтаксисом С/С++, что помогает многим пользователям почти сразу начинать писать программы на Gentee. Подобно языкам Java или С# исходный текст программы компилируется в промежуточный код, который затем выполняется виртуальной машиной."

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

Воплотить нечто подобное (не столь общее), несомненно, можно.
Легко перенести коды - однозначно нет. Потому что Text утянет за собой большую часть BB Framework, а он 1) базируется на свящзанных с типом процедурах 2) на метапрограммировании 3) на развитой run-time типизации. Ничего этого в Modula-2 нет.

В принципе, можно говорить о большей-меньшей эквивалентности возможностей CP-Java-C#. Что можно на одном, то можно и на другом. Единственное, что: CP значительно лаконичней и проще во многих аспектах, CP предоставляет конструкцию модуля.

По поводу Gentee ничего сказать не могу. Как я понял, нормальный, ничем не примечательный (полускриптовой) язык. Тот, кто выбирает его, получает новую "интересность" для изучения и наверняка новые глюки. Пример - Clarion. Кое-что можно сделать удобно, но шаг влево - шаг вправо - начинаются горы сложностей и кода. (Можете полюбопытствовать у Ивана Кузьмицкого, почему он со своей командой решил переходить с Clarion на BlackBox).

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

По поводу "выбора в массах компонентного ПО"...

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


Крупные интернет-приложения давно выполняются в native-стиле, на полноценных, компилируемых языках. PHP - максимум шлюз к БД...
Для коропоратвных инет-приложений сейчас прижился Oracle+Java. Корявая вещь, но тем не менее, оказался лучше, чем возня с двоичными объектными моделями типа CORBA и COM, и уж подавно лучше, чем скриптовые языки, которые здесь вообще неприменимы.
Посмотрим, как пойдут дела у .NET...

И что - будет в .NET миграция кода или нет? Это вообще преимущество или как сказать...?

Станет-то станет, но зачем? Кому это надо? Автоматически генерированные программы редко читабельны (возьмите хотя бы выход с YACC). А техническая совместимость обеспечивается обычно либо на двоичном уровне, либо на уровне промежуточного представления...
Кстати, в этом году на сентябрьской конференции в МГУ Е. Зуев (соавтор Zonnon - с Гуткнехтом) размышлял о целесообразности использования для такого представления XML...

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

На вопрос 1. YACC вышел из теории грамматики языков. Интерфейс теоретичен и математичен. Реализует лишь ограниченный класс языков, там где можно использовать автоматы. Дизайн не привязан к человеческой психологии, т.е. эргономические задачи не решались. Теперь по методу проектирования на YACC. Это процесс сверху-вниз на С++. Что-то я не встречал обратной операции преобразования с С++ в файлы YACC. Потом посмотрел я в полученный код на С++. Ничего непонял... Работает правильно но совершенно не отследить "КАК". Очевидно, что "универсальным" инструментом для трансляции с одного языка на другой он не станет. История уже расставила все i и очертила круг использования YACC.

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

• о аппаратно-программной среде (OS, x86)
• грамматике языка
• исходные коды библиотек, программ
• модель бизнес-процедуры
• справочную информацию

И все представления необходимо оформить с учётом восприятия человека (эргономика представления информации).

На вопрос 3. XML - это очередная мода и "заклинание". Все только и говорят о XML. Но давай смотреть в корень! Можно ли передаваемое описание оформить в классический TXT файл? Очевидно... Или, использовать в качестве контейнера знаменитый формат DBF? Можно... Сейчас на моей работе, а мы филиал и каждый день обмениваемся информацией с управлением, вместо DBF формата внедрили XML. Цель-то одна - передать и подключить информацию в базу. Кстати для XML нужно много чего доустановить, настроить пути к каталогам, чтобы всё правильно заработало и отображало. Для нашей задачи:" Что заворачивать-то в этот XML?" Как свернуть без потерь действительно жизненную информацию о проекте?

На - 4. Не только "между языками тесной группы вполне возможна" трансляция, но и далёких. Это вполне можно. Повторяюсь, но это важно - " Сравнение языков программирования Си++, Паскаль и Ада (Си, Модула-2, Оберон-2 и Ява) http://home.perm.ru/~strannik/st_txt_prog_02.html - реализовал идею универсального описания кода программ в сематические конструкции. Редактор в "Страннике" это не текст, а отражение структуры программы. При наличии конструкций языка транслировать по описанию грамматики в целевой язык - тривиальная задача.

Вот диаграмма этапов по трансляции с одного диалекта в другой (будет обобщение для различных целевых языков):

{Исходный язык} -> G1-грамматика языка -> P1-правила преобразование в сематическое описание -> БАЗА ЗНАНИЙ->P2-правила преобразование из сематического описания -> G2-грамматика целевого языка -> {Целевой код для диалекта языка} -> Компиляция в машинный код.

(Не путать с WIKI!!! Это набор справочной информации, но не база знаний в классическом понимании).

Зачем? Чтобы у программных кодеров был инстумент для накопления библиотеки подпрограмм на "уровне промежуточного представления. Один раз по-человечески опишем фрагмент программы - многократно начнём использовать!

Академический бред. Странслируй на оберон (вручную):


P.S. Странслировать можно, но это будет не читабельнее асм-подобного кода (что мы, кстати, и имеем в .NET).

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

Возражения про отсутствие обобщенки - справедливое, ну так обобщенку можно привернуть к любому языку, это, по сути, типизированные макросы, механизм, положенный поверх языка, и обрабатывающийся на этапе (ранней) компиляции, а не в run-time. (Подчеркну: можно привернуть к языку. Компилятор-то дорабатывать придется...)

В Ada, кстати, мне решение нравится - единица параметризации и инстанциирования - пакет. Иногда не так удобно, но более четко и бардака поменее. STL под нее перенесен, кстати.

Академический бред. Не согласен. Конечно нужно опустить руку в карман за словом... В настоящий момент готовлю заметку с исходными примерами на языках ASM, MODULA-2, C++ с простыми примерами - "Нарисовать окно", "Заголовок окна", "Текст в окне", "Кнопка управления" с целью автоматической генерации фрагмента кода для целевого языка.

По-поводу задания. Ответим на важные вопросы:
1. Можно перекодировать "в ручную" приведенный фрагмент программы?
2. Предложить представление описания, которым будет удобно пользоваться.

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

Да легко:

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