Здравствуйте, Дарней, Вы писали:
M>>Их сайт www.literateprogramming.com, там же есть статьи Д. Кнута. У меня есть порты TANGLE и WEAVE на Delphi, исходники TeX, ... Повторяю, все на уровне 1980-х годов
Д>похоже, сейчас начался новый виток спирали и к этой идее начали возвращаться. Глядишь, и получится что-нибудь дельное. Я и сам пытаюсь, по мере своих скромных сил, хоть что-нибудь реализовать.
Тот же Хаскель поддерживает комментарии в стиле литературного программирования. Т.е. вместо
-- Это комментарий, а ниже код
main :: IO ()
main = putStr "Hello world"
можно писать
Это большой-пребольшой комментарий,
да и весь текст по большей части является комментарием
> main :: IO ()
> main = putStr "Hello world"
Отдельного прероцессинга не требуется. Чтобы компилятор мог понять что к чему, ЛП-файлам дается иное расширение, или ключами компиляции.
Здравствуйте, Костя Ещенко, Вы писали:
КЕ>Тот же Хаскель поддерживает комментарии в стиле литературного программирования. Т.е. вместо КЕ>[c] КЕ>-- Это комментарий, а ниже код
Ну... это просто стиль коментариев такой, а не стиль литературного программирования... Отсутствует основная идея --- на выходе должна быть книга, описывающая программу. По мелочам:
1. Нет языка разметки текста.
2. Нет возможности вставить в текст программы дополнительные возможности по оформлению. Например, я хочу, чтобы в распечатке программы использовался символ пустого множества, как иногда делается в книгах при неформальном описании алгоритмом на множествах (в частности на графах)
3) нет воможности для построения индекса имен, который бы использовал не только данные программ, но и в комментариях. В частности, как по такому коментарию сформировать раздел "Список используемой литературы", в которой указать все ссылки на литературу из кода/коментариев???
4) как вставить, например, рисунок со схемой?
5) нет возможности для разбиеная кода на секции таким образом, чтобы название секции включало содержательный текст (с формулами и т. д.) Это часто используется при неформальном описании алгоритмов.
В целом литературное программирование очень сильно ориентировано на решение в первую очередь алгоритмических задач.
Здравствуйте, Mystic, Вы писали:
M>Ну... это просто стиль коментариев такой, а не стиль литературного программирования... Отсутствует основная идея --- на выходе должна быть книга, описывающая программу. По мелочам: M> 1. Нет языка разметки текста. M> 2. Нет возможности вставить в текст программы дополнительные возможности по оформлению. Например, я хочу, чтобы в распечатке программы использовался символ пустого множества, как иногда делается в книгах при неформальном описании алгоритмом на множествах (в частности на графах) M> 3) нет воможности для построения индекса имен, который бы использовал не только данные программ, но и в комментариях. В частности, как по такому коментарию сформировать раздел "Список используемой литературы", в которой указать все ссылки на литературу из кода/коментариев??? M> 4) как вставить, например, рисунок со схемой? M> 5) нет возможности для разбиеная кода на секции таким образом, чтобы название секции включало содержательный текст (с формулами и т. д.) Это часто используется при неформальном описании алгоритмов.
M>В целом литературное программирование очень сильно ориентировано на решение в первую очередь алгоритмических задач.
Хаскель поддерживает альтернативный LaTeX-совместимый синтаксис литературных комментариев — комментарием является все строки, не заключенные в теги \begin{code}...\end{code}, а в остальном полная свобода. Думаю, это решит все перечисленные тобой пункты, кроме #2 (#5 я не совсем понял).
Сорри, что сразу не сказал — сам не помнил, видимо раньше пропустил эту фичу как несущественную.
Здравствуйте, Дарней, Вы писали:
Д>В общем, plain text must die
Я давно так считаю. В 2005-м году барахтаться в plain-text — это каменный век. Plain text — не управляем, не верифицируем, не гибок, с большим трудом параметризуем (шаблоны С++ имеют массу ограничений, генерики C# — вообще курам на смех) и т.д. Инструменты рефакторинга существуют только для очень небольшого кол-ва языков.
Хочется иметь в общем виде банк алгоритмов, структур, объектов, протоколов, целых подсистем и т.д. Все эти модели кода могут иметь параметры. Написание программы могло бы сводится к параметризации моделей и их взаимной "стыковке", путем написания других моделей (и одновременного обогащения репозитория кода). Проблемы верификации, типобезопасности и пр. решались бы сами по себе...
--------
Однако, нард весьма агрессивно не приемлет саму подобную концепцию, и, к сожалению, многие "профи" в т.ч.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Кодёнок, Вы писали:
Кё>>Я тоже за это, но пусть хоть кто-нибудь хоть какой-нибудь реальный пример приведёт, чтобы убедиться, что это возможно Ну например? Что надо добавить в C#, чтобы он научился делать объекты-генераторы из обычного кода, при условии, что это специально не предусмотрено? Т.е. возможности расширения настолько общие, что позволяют сделать yield, но не созданные специально для него?
VD>Нужно добавить некий макрос который встретив например: VD>
VD>yield_return(x);
VD>
VD>поймет, что нужно преобразовать это дел в конечный автомат.
(поиск рулит, да
Я правда не доделал возможность рекурсивных вызовов — для этого нужно в базовый класс зафигачить стек вызовов.
VD>Если появится возмжность еще и новые ключевые слова добавлять, так это вообще будет здорово. Но я и так буду счаслив.
Макросы — чем не ключевые слова?
По-поводу DSL —
1) boost::spirit сам по себе DSL
2) С его помощью легко созадать компилятор DSL-языка.
Правильно работающая программа — просто частный случай Undefined Behavior
Здравствуйте, pvgoran, Вы писали:
P>Там в заглавии статьи/презентации явно говорится про "death of computer languages". И это, кстати, даже и не про DSL.
вопрос — а где результаты? (посмотри на дату в статье)
похоже, что автора статьи только за смертью и посылать
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Дарней, Вы писали:
Д>>В общем, plain text must die
V>
V>Я давно так считаю. В 2005-м году барахтаться в plain-text — это каменный век. Plain text — не управляем, не верифицируем, не гибок, с большим трудом параметризуем (шаблоны С++ имеют массу ограничений, генерики C# — вообще курам на смех) и т.д. Инструменты рефакторинга существуют только для очень небольшого кол-ва языков.
...
V>-------- V>Однако, нард весьма агрессивно не приемлет саму подобную концепцию, и, к сожалению, многие "профи" в т.ч.
Так в чем вопрос? Реализуй подобного рода систему, покажи все ее преимущества Заодно узнаешь о недостатках Да, любому бинарному формату можно сопоставить аналогичный текстовый формат, самое тривиальное --- MIME.
M>Так в чем вопрос? Реализуй подобного рода систему, покажи все ее преимущества
Действительно, какая ерунда. Мне думается, что над редактором текста исходников в той же VS2005 работало как минимум человек 10. На мой взгляд, команда из примерно 25-30 чел вполне могла бы сделать нечто подобное за год (альфа-версию)
M>Заодно узнаешь о недостатках
О недостатках чего именно? Я себе представляю этот редактор в виде free-way одновременного редактирования кучи представлений кода: исходник, UML (или нечто близкое), AST, набор св-в на каждый узел, "свертки" в исходниках (уже есть в современных редакторах) с редактированием параметров этих сверток и вынесением в репозиторий (вставка из репозитория) и т.д. Если кто-то привык редактировать только исходники + intellisence, то это у него никто отнимать не собирается.
Нечто двигающееся в этом направлении есть у Together, с их репозиторием паттернов (любой свой кусок кода можно сохранить как параметризованный паттерн), с двунаправленным редактированием UML, кода, и панели св-в, которая достаточно умна, чтобы различать элементы кода (что не так просто, ИМХО, для примера, Java-коментарии в этой среде гораздо удобнее набивать чем в IDEA).
В общем, именно работа в Together пару лет назад твердо укрепила в мысли, что plain-text must die. Они находятся в самом начале пути, но идут в нужном направлении. Любой открываемый текстовый файл там переводится во внутреннее представление, прежде чем мы получаем доступ к редактированию. Тот факт, что они оперируют именно с внутренним представлением прямо-таки чуствуется "под пальцами", когда сидишь в этой среде.
Здравствуйте, Mystic, Вы писали:
M>Так в чем вопрос? Реализуй подобного рода систему, покажи все ее преимущества Заодно узнаешь о недостатках Да, любому бинарному формату можно сопоставить аналогичный текстовый формат, самое тривиальное --- MIME.
Надеюсь, ты представляешь себе объем работ?
Я конечно пытаюсь воплотить некоторые идеи в жизнь. Сделать пусть и не полноценную систему, но хотя бы каркас, на который можно будет прикручивать плагины. На данный момент проект находится на стадии "конь не валялся"
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Mystic, Вы писали:
M>>Так в чем вопрос? Реализуй подобного рода систему, покажи все ее преимущества
V>Действительно, какая ерунда. Мне думается, что над редактором текста исходников в той же VS2005 работало как минимум человек 10. На мой взгляд, команда из примерно 25-30 чел вполне могла бы сделать нечто подобное за год (альфа-версию)
А что там сложного? TeX, Oberon примеры достаточно сложных систем, реализованых небольшими коллективами
M>>Заодно узнаешь о недостатках
V>О недостатках чего именно? ...
Я понял наше отличие Я по натуре одиночка, мне проще работать в небольшом коллективе профессионалов. Вот сейчас проект: свой язык программирования (достаточно простой), IDE, отладчик. Два человека, один год И по моим оценкам редактор исходников для конкретного языка программирования подобный VS2005 это максимум человеко-год Но тут огромную роль играет тот факт, что ты сам совмещаешь аналитическую работу и работу над проектом.
Здравствуйте, Дарней, Вы писали:
Д>Надеюсь, ты представляешь себе объем работ? Д>Я конечно пытаюсь воплотить некоторые идеи в жизнь. Сделать пусть и не полноценную систему, но хотя бы каркас, на который можно будет прикручивать плагины. На данный момент проект находится на стадии "конь не валялся"
Да, я представляю... И у меня есть давняя мечта: накопить денег на пару лет жизни и раняться реализацией своих идей Только эконом из меня никудышний
Здравствуйте, Павел Кузнецов, Вы писали:
Д> В общем, plain text must die. Д> ... упрощается создание средств рефакторинга и визуализации, контроль изменений и просмотр истории, и т.д.
ПК>Имхо, наоборот, все значительно усложняется: сейчас есть масса средств, работающих с plain text.
А зачем тогда сделано нитевое представление дискуссий в RSDN?
Здравствуйте, Дарней, Вы писали:
P>>Там в заглавии статьи/презентации явно говорится про "death of computer languages". И это, кстати, даже и не про DSL.
Д>вопрос — а где результаты? (посмотри на дату в статье)
Хороший вопрос . Меня он тоже занимает...
Д>похоже, что автора статьи только за смертью и посылать
Вообще-то, некое оправдание у автора есть: раньше он работал "под крылом" Microsoft, который вполне мог не давать "развернуться", потом вроде бы создал собственную фирму (Intentional Software) и сейчас что-то там делает.
Кстати, на сайте Intentional Software есть небезынтересные блоги по их деятельности.
(поиск рулит, да _W>Я правда не доделал возможность рекурсивных вызовов — для этого нужно в базовый класс зафигачить стек вызовов.
Ага. Вот на С++ почти все решения такие. Через задницу и с большим количеством осложнений.
Хотелось бы иметь инструмент позволяющий делать все так как хочется и без побочных эффектов. У тебя побочные эффекты появляются сразу, но это еще цветочки. Ведь есть еще такие вещи как рефакторинг и интелисенс. У них быстро крышу сорвет от таких вот текстуальных наворотов.
VD>>Если появится возмжность еще и новые ключевые слова добавлять, так это вообще будет здорово. Но я и так буду счаслив. _W>Макросы — чем не ключевые слова?
Тем что они вообще не имеют никакого отношения к коду. Это просто текстовые подстановки. С тем же успехом я могу использовать С++-ный препроцессор и для C# c VB. Только почему-то не хочется.
_W>По-поводу DSL — _W>1) boost::spirit сам по себе DSL
Несомненно. Вот только опять же слишком много побочных эффектов и ограничений. Хотелось бы иметь возможность делать нечто похожее, но без всего этого геморроя и без ограничений.
_W>2) С его помощью легко созадать компилятор DSL-языка.
Легко? Ну-ну. С его помощью можно создавать парсеры примитивных языков. А для более серьезных один фиг потребуются более серьезные парсеры. А ведь в компиляторе еще есть куча всего кроме парсера.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Да, любому бинарному формату можно сопоставить аналогичный текстовый формат, самое тривиальное --- MIME.
