Лог с двух IRC каналов — обсуждение данного "проЭкта":
* Сейчас общаетесь на #lisp
<egp_> x., а метапрограммирование языка в язык (например, C/C++ в Оберон) тебе интересно?
<egp_> я щас решил этим вплотную заняться
<egp_> Оберон будет расширенный, для метапрограммирования кода БЕЗ ПОТЕРИ СЕМАНТИЧЕСКОГО СМЫСЛА КОДА
<egp_> из С++ и С в кастомный расширенный Оберон
<egp_> более подробно - в конце треда описано тут:
viewtopic.php?f=28&t=3954&p=73128#p73128<egp_> могутный суперамбициозный проект, но зато интересно.
<x.> а какие оно имеет перспективы на сегодняшний день? писать сложный проект стоит хотябы ради чего-то. чтобы пользоваться самому или чтобы хоть кто-то этим пользовался
<x.> а проект, по-моему недостаточно сложный, чтобы стала интересна сама сложность, тут 95% рутина
<egp_> x., ну тут такой вот интерес (кстати оч хороший вопрос).
<egp_> мне вот на данный момент оч интересны референциально целостные языки
<egp_> C и С++ такими языками не являются.
<egp_> у них обязательно требуется такой клей как мейкфайлы - для склеивания референций в коде на си-си++
<egp_> а вот хочется язык, где референции объявляются более явно и более прозрачно
<egp_> оберон и ява - это некоторые шаги в этом направлении.
<x.> только что хотел джаву предложить
<x.> оберон это же говно мамонта, пардон
<egp_> а вот например ребол объявляет все референции в явном виде - это либо локальные файлы либо урлы
<egp_> нене. в целом оберон как явление меня не интересует, меня интересуют его позитивные аспекты некоторые
<egp_> есть такая хорошая пословица как "Literal-mindedness is good."
<egp_> Она говорит как раз о том что КЛЕЙ надо представлять литерально-явно, и без умолчаний типа "НУУУУ КАААААК НИБУУУЦЦЦЬ СЛИНКУУУУЕМ". То есть это исследования идей в области референциальной явности
<egp_> в яве есть такое явление как classpath hell, это большой минус
<egp_> импорт библиотек должен быть более явным, в похожем направлении работает ява-проект Maven
<egp_> (я с Maven правда пока не разбирался)
<egp_> мейкфайлы делают почти невозможным метапрограммирование
<x.> почему это?
<egp_> тогда как Оберон в силу почти максимальной простоты синтаксиса (самый простой синтаксис, безусловно, у лиспов) гораздо удобнее для метапрограммирования нежели си, си++, ява.
<egp_> ну например как распарсить семантику мейкфайла ты представляешь себе? мне кажется это сложновато...
<egp_> вот простота синтаксиса и есть один из больших плюсов оберона.
<egp_> x., просто я очень уверен в том, что использовать make для сборки - это стрельба инструментом типа ПУШКА по задаче типа ВОРОБЕЙ...
<egp_> make сильно круто для такой простой задачи, как простейшая штука - референция.
<x.> если задача простая, можно самому вызывать компилятор, кто мешает
<egp_> мешают традиции: общепринято юзать make
<egp_> просто как сверхзадача — хочется упростить менеджмент процесса производства такой бесплатной ОС как линух плюс гну сьют
<egp_> а такие залипухи как Makefiles этому сильно-пресильно мешают.
<egp_> вот хочется другой язык для референциальной целостности, НЕ язык make
<egp_> в языке make явно и-или неявно используется масса языков из комплекта гну сьют.
<egp_> и это страшная и ИЗЛИШНЯЯ залипуха.
<egp_> сам GCC — уже огромнейшая и ИЗЛИШНЯЯ залипуха — всё можно и нужно сделать намного проще и чтобы шустрее работало. И это полностью возможно, я уверен. Только работы в этом направлении дофигища.
<egp_> вот плюс оберона в том, что у него НАМНОГО шустрее парсинг нежели у явы и тем более у си-подобных языков. И скорость парсинга оберона — не предел совершенства. Предел совершенства скорости парсинга — у визуальных языков, которые хранят код в бинарных файлах
<egp_> и редактирование кода происходит в спец инструменте.
<egp_> ну, тут речь о парсинге кода на данном языке.
<egp_> и вот возможно я не в оберон буду метапрограммировать, а в такой вот бинарный визуальный язык. Тут небольшое сходство с обероновой идеей Juice/Slim Binaries.
<egp_> просто софт должен быть проще и шустрее, и таким вот макаром эти два показателя можно значительно повысить.
<egp_> Для достижения этого дела придётся переписывать тыщи мейкфайлов.
<egp_> То есть Разгребать все эти авгиевы конюшни.
<egp_> y. с канала #forth пишет в ответ на это: "да-да, это правильно". egp_ пишет в ответ: вотвот. гут, что есть согласие.
<egp_> <y.> а я вообще целом, считаю что большинство мэйнстримовых ЯП движутся в тупик
<egp_> <egp_> да они ждут просто здравых идей
<egp_> <y.> да, не спорю - делают много хороших программ и ОС
<egp_> <y.> но вот и больше ничего
<egp_> <egp_> а пока здравых идей нет, всё идёт на самотёке, то есть как попало
<egp_> <egp_> ну вот эта метапрограммная идея про "всё упростить и ускорить" и "убрать мейкфайлы" --- хрен сделаешь. Как-то надо вывернуться подобно тому как Линус штангу поднял...
<egp_> <y.> за полвека развития — развитие в основном экстенсивное
<egp_> в принципе возможно у меня найдутся соратники в списках рассылки вроде os.dev
<egp_> <egp_> в принципе явовский Maven + явовский ant — это шаг к лучшему по сравнению с make... но тоже далеко не всё хорошо, сильно выразительные языки — излишняя выразительность тут не нужна совсем.
<egp_> <egp_> вот... в принципе можно попробовать как-то подобную платформу инициировать... как это лучше осуществить — не очень понятно.
<egp_> <y.> ну, в данной ситуации мне видится разве что качественный переход на какую-то новую платформу разработки ПО
<egp_> <y.> принципиально новую
<egp_> <egp_> короче эту новую платформу я обозначу кодовым словом Phial, реинкарнация первая... просто от балды словечко
<egp_> <egp_> и начну с того что —
<egp_> <y.> хех, фиалка )
<egp_> <egp_> возьму ревизию GCC которая поставляется с убунтой (то есть считается достаточно стабильной) и аккуратно переделаю эту ревизию в кодогенератор кода в некоем более-менее оптимальном бинарном визуальном языке.
<egp_> <egp_> Потом сооружу визуальный редактор для этого языка.
<egp_> <egp_> Ну тут ещё ассоциация с roguelike артефактом Phial of Galadriel
типа вечный светильник
<egp_> <y.> а, вон оно как
Вход
FAQ
Поиск
