OberonCore
https://forum.oberoncore.ru/

"Язык с динамически мутирующим синтаксисом"?
https://forum.oberoncore.ru/viewtopic.php?f=28&t=76
Страница 3 из 7

Автор:  Илья Ермаков [ Понедельник, 26 Декабрь, 2005 22:50 ]
Заголовок сообщения: 

Vlad писал(а):
пока единственно известного мне "реального" обероновского продукта.

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

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

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

Автор:  Сергей Оборотов [ Понедельник, 26 Декабрь, 2005 23:12 ]
Заголовок сообщения: 

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

Автор:  Vlad [ Понедельник, 26 Декабрь, 2005 23:58 ]
Заголовок сообщения: 

Илья Ермаков писал(а):
Жабу и С# не трогаем, это новое поколение.


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

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


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

Илья Ермаков писал(а):
Остальные типа С наклали на все аксиомы Дейкстры, Хоара, Вирты, Кнута и продолжали пропагандировать корявый полумашинный подход.


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

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


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

Илья Ермаков писал(а):
Что касается фирмы - с января начинаем писать систему бизнес-планирования, прототип думаем получить к середины весны.


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

Автор:  Илья Ермаков [ Вторник, 27 Декабрь, 2005 03:50 ]
Заголовок сообщения: 

Цитата:
Vlad писал(а):
Илья Ермаков писал(а):
Жабу и С# не трогаем, это новое поколение.


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

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

Автор:  vladfind [ Вторник, 27 Декабрь, 2005 14:12 ]
Заголовок сообщения: 

GUEST писал(а):
* Какую цель преследует неэлементарное решение задачи, которая имеет элементарное решение?
* И, наконец, сколько Вам понадобится ресурсов, чтобы закончить Ваш проект?


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

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


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

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

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

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

Автор:  Info21 [ Вторник, 27 Декабрь, 2005 17:25 ]
Заголовок сообщения: 

Vlad писал(а):
С - системный язык и никто лучшего пока не придумал.


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

Автор:  Vlad [ Вторник, 27 Декабрь, 2005 21:14 ]
Заголовок сообщения: 

Илья Ермаков писал(а):
Сетевое ПО отличное, сервера, браузер и т.п. есть. Вот последнюю версию дали посмотреть - красотища не хуже XP.


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

Илья Ермаков писал(а):
Скажите мне, почему MS VC++ весит более 2 Гб?


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

Илья Ермаков писал(а):
Две вещи решают проблемы раз и навсегда: GC + строгие проверки


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

Автор:  Vlad [ Вторник, 27 Декабрь, 2005 21:30 ]
Заголовок сообщения: 

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


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

Автор:  Vlad [ Вторник, 27 Декабрь, 2005 21:42 ]
Заголовок сообщения: 

info21 писал(а):
Vlad писал(а):
С - системный язык и никто лучшего пока не придумал.


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


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

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

Автор:  Vlad [ Вторник, 27 Декабрь, 2005 21:49 ]
Заголовок сообщения: 

vladfind писал(а):
а) Выделить нужным цветом комментарий;


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

Автор:  Сергей Оборотов [ Вторник, 27 Декабрь, 2005 23:00 ]
Заголовок сообщения: 

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

Автор:  Илья Ермаков [ Вторник, 27 Декабрь, 2005 23:33 ]
Заголовок сообщения: 

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

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

Автор:  Илья Ермаков [ Вторник, 27 Декабрь, 2005 23:49 ]
Заголовок сообщения: 

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


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

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

Автор:  Илья Ермаков [ Вторник, 27 Декабрь, 2005 23:53 ]
Заголовок сообщения: 

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


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

Автор:  Илья Ермаков [ Среда, 28 Декабрь, 2005 00:11 ]
Заголовок сообщения: 

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

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

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

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

Автор:  Vlad [ Среда, 28 Декабрь, 2005 01:50 ]
Заголовок сообщения: 

Илья Ермаков писал(а):
Только дело-то в том, что решаются проблемы потребителя, который получает более надежное ПО. В разы надежное зачастую.


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

Автор:  Илья Ермаков [ Среда, 28 Декабрь, 2005 02:03 ]
Заголовок сообщения: 

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

Автор:  Илья Ермаков [ Среда, 28 Декабрь, 2005 02:17 ]
Заголовок сообщения: 

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


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

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

Автор:  Vlad [ Среда, 28 Декабрь, 2005 07:48 ]
Заголовок сообщения: 

Илья Ермаков писал(а):
Дело в том, что объемы разработок Microsoft растут непропорционально их возможностям (они тоже растут бытро, но не настолько :-)


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

Илья Ермаков писал(а):
Если бы каждый более мощный компьютер становился больше предыдущего?


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

Илья Ермаков писал(а):
Размер очень даже волнует. Это неоценимое удобство - иметь возможность в любое время в любом месте воткнуть флешку и без интсалляции начать работать.


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

Илья Ермаков писал(а):
Кстати, очень раздражает необходимость инсталляции для тех продуктов, которым она особенно не нужна.


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

Автор:  Vlad [ Среда, 28 Декабрь, 2005 07:51 ]
Заголовок сообщения: 

Илья Ермаков писал(а):
.
В информатике есть три формальных теории алгоритмов: 1) на основе машины Тьюринга 2) на основе рекурсивных функций 3) на основе символьных цепей и нормальных алгорифмов Маркова.
Вот о последней парадигме и упоминал уважаемый info21.


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

Страница 3 из 7 Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/