OberonCore

Продуктов таких не много, зато каждый стоит внимания. На неделе наконец откроем раздел сайта "Проекты", где дадим информацию обо всех идущих в России проектах.
Пока для затравки - старейшие российские компиляторщики и оберонщики (работают с 1984 г.) - новосибирская компания Excelsior. Их старая разработка - пакет XDS кросс-разработки, в т.ч. для встроенных систем (Модула-2, Оберон). Сейчас сам продукт Freeware, а компания подалась в Java-инструментарий (пакет JET). Предвижу злорадную усмешку... Но не спешите радоваться: делают они этот Java-инструментарий на Обероне-2.
Вот он их сайт:
http://www.excelsior-usa.com

А в Европе вещей интересных тоже довольно много. Операционка BlueBottle - вроде бы экспериментальная разработка, начиналась как диссертация, а теперь вполне рабочая вещь. Если бы базу драйверов поднять до уровня Линукс, то цены бы не было. Сетевое ПО отличное, сервера, браузер и т.п. есть. Вот последнюю версию дали посмотреть - красотища не хуже XP.

Что меня покорило в обероновских разработках - это то, что хорошие вещи здесь создаются гораздо быстрее, легче и меньшим числом людей (два-три-пять-десять). И дело здесь не в самом языке, а в стиле мышления, наверное. Скажите мне, почему MS VC++ весит более 2 Гб? Что в нем такого, что стоит такого объема? Просто банальная лень и нежелание искать хороших решений. Принцип хаотичного нагромождения. Сначала налабаем чего-нибудь, потом погоняем в отладке, потом поглядим, что получилось. А что глюков много - так MS месячник борьбы с ошибками очередной объявит. Все сидят и ловят глюки И поймают - тысячи-то человек да целый месяц... А столько же все равно останется... Я утрирую, конечно, но подход именно такой. Вот книжка недавно вышла: Дж. Роббинс "Профессиональная отладка". Умная книжка, мужик опытный, собаку съел на борьбе с багами, разработке отладчиков и инструментария отлова ошибок памяти (Numega). Годы упорной работы. На каждой странице - воспоминания про то, как когда-то ушла неделя-две-месяц, на то, чтобы найти особенно хитрый повисший указатель либо утечку памяти. Полгода назад я читал и думал: круто. Потом увидел, что не круто, а переливание их пустого в порожнее. Две вещи решают проблемы раз и навсегда: GC + строгие проверки, например, границ массива. Почему не используют? Гордость? Мы сами с усами? Я предпочитаю свое время и силы направлять на нечто более продуктивное...

Осталось невыясненным два вопроса, vladfind. Какую цель преследует неэлементарное решение задачи, которая имеет элементарное решение?
И, наконец, сколько Вам понадобится ресурсов, чтобы закончить Ваш проект? Хотелось бы напомнить, что тема начиналась с заявления о инновационной технологии. По крайней мере до её переноса в отдельный блок.

Ну сам Вирт так не считает...



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



Ох, зря ты сюда Кнута вписал... Никто ни на кого не наклал. С - системный язык и никто лучшего пока не придумал.



И чего? Какие-нибудь смолтолковцы вообще сразу повесились бы... Твой пример может лишь доказать близость концепций Ады и Дельфей. Хотя лично меня такая близость может лишь насторожить



А конкретный заказчик есть? И вообще нескромный вопрос - кто платит за эту НИР?

Ну сам Вирт так не считает...[quote]
Касательно Оберонов - конечно, не считает и правильно делает
Я имел в виду Ada и Modula-2.

---
По поводу того, "кто финансирует НИР": доход от мелких заказов + баа-льшой энтузиазм
Бизнес-план - проект не под конкретного заказчика, а под конкретный конкурс на инвестиции. Хорошие наработки по теме у наших экономистов уже есть, но реализацию начинаем только сейчас. Так же и с СУБД.
Год работали на C++ Builder и Delphi. Весной намеревались сделать основной Ada-95, но время все расставило по-другому

Кажется всё перечислил. Если в части "неэлентарно-элементарное", например раскрасить текст на языке программирования. В редакторе Jedit имеются xml в разделе module для раскраски тестов на различных языках программирования. Но умеет не всё. В часности вложенные конструкции "Комментарий" реализация на xml в jedit не умеет делать правильно.

В базе знаний фрагмент кода программы "Комментарий" будет хранится в виде конструкции:
"Начало_комментария","Символы_начало","Тело_комментария","Конец_комментария","Символы_окончание".
Для каждого диалекта заменяем "Символы_начало", "Символы_окончание".

На основании предложенного способа хранения конструкции языка программирования можно, и очень просто:
а) Выделить нужным цветом комментарий;
б) Генерировать новый исходный код программы в соответствии с соглашением о кодировании ( отступы, перенос комментариев, добавление новых к функциям и т.д.);
в) Однозначно транслировать и оформлять комментарии для других диалектов языков программирования: '!' - Clarion; '(* *)'-C++; '/* */'- Pascal, Modula; '//' - 1C, '%' - Prolog и т.д.

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

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

Почему оптимизм не покидает меня? Летом испытал компоненты робота-программиста в среде 1С. Решил задачу кодогенерации модуля экспорта-импорта элементов справочников. Получил увеличение производительности создание проф. кода для импорта-экспорта справочников на порядки (!). Обработка самостоятельн, на основании особенностей описания в конфигурации конкретных справочников, выбирает способ реализации фрагментов программы. Значит, чтобы быстро "ездить" в будущем, необходимо максимально медленно подготовится сейчас.

Да Оберон лучше, блин. Сколько нужно ..., чтобы это понять...

Я такое слышу со времен появления линукса. А воз и ныне там - десктопы за виндой.



А что? Можешь привести пример подобного продукта меньшего объема? Я даже не буду упоминать, что объем, занимаемый на диске, вообще никого не волнует.



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

А мелкие заказы на чем делаете?

Немного. Хотя бы примеров успешного внедрения вне стен институтов. Когда я последний раз смотрел статистику на sourceforge, количество проектов на обероне было 0.

P.S. Кстати, я увижу ссылку на практику применения "марковских языков"? А то google молчит как партизан...

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

Не стоит толочь воду в ступе. Если хотите, Влад, подумайте из какого промежуточного представления мог возникнуть твой пример на С++. А нам с лихвой хватит проблем с представлением Oberon-программ.

Если приложения - на ББ. Если сайты - то ясно, что не на нем, а на PHP.
Сейчас веб-программисты доделывают движок для интрнет-магазина, а клиентская администраторская часть будет сделана на ББ. Либо коннектиться к СУБД на хосте, либо через сокеты - еще не решили.

Дело в том, что объемы разработок Microsoft растут непропорционально их возможностям (они тоже растут бытро, но не настолько Такое ощущение, что волочится груда хлама, которую просто лень вырезать, либо боятся трогать. В чем причина того, что объем WinXP в полтора раза больше 2K? Внутренне и технологически абсолютно эквивалентные системы. Почему VC .NET должна в пять раз превышать объем VC 5.0? Я понимаю, что она в десять раз мощнее, ну так не экстенсивным же путем это достигнуто... Если бы каждый более мощный компьютер становился больше предыдущего?

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

excelsior-usa.com посмотрели? Да, единственная компания в России, зато работают уже 20 лет - и успешно работают. Да, пришлось уйти из Оберон-инструментария в Java-инструментарий (Их виртуальная машина JET имеет сертификат Sun и признана очень удачной разработкой). Но пишут этот самый JET все равно на Оберон-2. Целиком! Не ищите прямых упоминаний на сайте, но это именно так. Можете, если хотите, у них спросить.

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

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

Кстати, на быстродействии Компонентного Паскаля в сравнении с Java и C# сказывается тот факт, что в последних все структуры данных динамические, в то время как в первом можно все, для чего не нужна динамика, сделать статически и в стеке. Для мелкиз служебных объектов, которые создаются и уничтожаются десятками - преимущество весомое.
Можно даже для одного типа объяить разные связанные процедуры:
PROCEDURE (p: PointerToType) Proc1
PROCEDURE (VAR t: Type) Proc2.
Первую можно вызывать только для указателей. Если напишем стат_перем.Proc1 - компилятор заругается.
Вторую - и для статических, и для указателей. В последнем случае просто произойдет неявное разыменование.

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

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

Про практику применения ничего не скажу, но краткий ликбез про то, что это такое, могу устроить.
В информатике есть три формальных теории алгоритмов: 1) на основе машины Тьюринга 2) на основе рекурсивных функций 3) на основе символьных цепей и нормальных алгорифмов Маркова.
Вот о последней парадигме и упоминал уважаемый info21. Сфера применения, насколько я понимаю, та же, что и академических функциональных языков. И info21, насколько я знаю, отказался от них именно из-за того, что на практике они оказались сложноприменимыми. В отличие от Оберона, который есть язык предельно практичный. Академическая, но не теоретическая разработка - чуешь разницу? Ничего в Обероне не выдумано "из башки", все естественно и имеет прикладной смысл. Чего-то не хватает - ну так уже 15 лет наращивают - и О2 (94), и КП(94-98), и Зоннон, наконец, выйдет. Только наращивают постепенно, сначало пять раз подумают, "репу почешут", а потом уже добавляют. Добавить просто - убрать потом сложно. (И если будет желание возражать, что "все давно делают, а они только думают" - то я ведь не случайно даты в скобочках привел. В 94 от чисто оберонского ООП окончательно пришли в виртуальным связанным процедурам. Однако за счет явного параметра избежали лишних и мешающихся внутриобъектных пространств имен. К 98 году сформировался Компонентный Паскаль - с четко выделенными архитектурными конструкциями для компонентного ПО. C# еще только маячил на горизонте. Про Зоннон уже не говорю. Зело грузен и дороден язык конструкциями разными, в том числе принципиально новыми.)

Да, на основе теории Маркова, насколько я помню, в 60-х В.Турчиным (он ныне в Штатах) был сделан русский Лисп - РЕФАЛ, на основе двунаправленных списков, для обработки символьных цепей. Непосредственно из той степи (да кабы не Турчин в них сам и участвовал) выросли и SGML, и XML, кстати.

А почему они должны расти пропорционально? Это какой-то фундаментальный закон развития ПО? А про "ощущения" можно поговорить за кружкой пива: "программы были меньше, трава зеленее и т.д."



Энергии десктопные компы стали жрать больше. Факт.



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



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

Можно привести пример(ы) марковских языков?