Здравствуйте, machine3000, Вы писали:

M>Не все языки живут сами по себе.

Гы. Вроде как я с этого и начал. Язык не вещь в себе, а обитает в среде различных инструментов. И эта среда не примет новый язык, только на основании того, что он лучше сам по себе. А быть "лучше" для всех в данной среде обитания — это и быть тем языком программирования, который в этой среде сформировался.

M>У тех, кто их продвигает, есть масса инструментов. Например, раздал ВУЗам IDE бесплатно или конкурс какой-нибудь устроил для студентов с призом ноутбук и т.д. А студенты — это считай новая экологическая ниша.

Там занята ниша. Паскалем, например (как языком созданным для обучения, и действительно долго эту нишу занимавшим).
Собственно говоря, было бы столько денег — проблем бы не было. Дале денег преподавателям, они бы заставили студентов не только учить — но и помогать развивать новый инструмент. Только примеры OCaml и прочих показывают — этого не достаточно. Кстати, интересно — а почему этого не достаточно оказалось?

Здравствуйте, cl-user, Вы писали:

CU>Хоть убейте — я так и не увидел тех. описания проблемы и описания её решения с пом. рассматриваемой "парадигмы".

Ты пользовался решарпером?

Здравствуйте, VladD2, Вы писали:

VD>Да, подумайте. Тогда может и не будете обсуждать это на форумах в сотый раз. Для меня очевидно, что наличие плоского текстового формата хранящего исходные коды для некого ЯП — это очень удобно хотя бы потому, что код можно читать и править вообще без спец.средств. Кроме того это позволяет без каких бы то нибыло затрат использовать целую массу удобного софта работающего с плоским текстом (например, SVN или сливалки текста).

В общем, всё сводится к одному — поддержка legacy приложений и инструментов.

VD>Толку же в хранрении бинарников я не вижу никакого. Может это и упростило бы компилятор за счет того что можно было отказаться от парсера, но не сильно. Учитывая же, что без импорта и экспорта в другие форматы все равно не обойтись (при наличии АСТ в бинарном виде), то вообще не ясно о чем собственно говорить.

Нет необходимости выполнять преобразование туда<->обратно на каждый чих пользователя (со всеми вытекающими последствиями в виде дополнительных багов и затрат ресурсов). Решарпер например отличная программа, но как же меня достали ее баги и пожирание ресурсов — это просто неописуемо. А если сюда добавить еще какой-нибудь диаграммер и анализатор кода (которые тоже каждый создают свое представление кода в виде AST), то вообще полная труба.
Если код парсится один раз — когда пользователь его вводит или модифицирует, а дальше все манипуляции выполняются только над AST, то это сильно упрощает создание инструментов разработчика.

Здравствуйте, mkizub, Вы писали:

M>Я искренне не вижу смысла в формализации обсуждаемого вопроса.

Опа... А ссылки есть? Ну дай хоть что-нибудь. А то и обсуждать то нечего...

P.S. А ещё говорят "лисперы злые — ничего не объясняют", так у них (у нас ) хоть документации "вагон и маленькая тележка"

Здравствуйте, Andrei F., Вы писали:

AF>Здравствуйте, cl-user, Вы писали:

CU>>Хоть убейте — я так и не увидел тех. описания проблемы и описания её решения с пом. рассматриваемой "парадигмы".

AF>Ты пользовался решарпером?

Это формализация проблемы?

Нет.

Здравствуйте, cl-user, Вы писали:

CU>Это формализация проблемы?

Проблема — это выполнение больших объемов избыточной работы по преобразованию данных. Удаление избыточной работы должно, естественно, устранить проблему

Здравствуйте, mkizub, Вы писали:

M>>Не все языки живут сами по себе.

M>Гы. Вроде как я с этого и начал. Язык не вещь в себе, а обитает в среде различных инструментов. И эта среда не примет новый язык, только на основании того, что он лучше сам по себе. А быть "лучше" для всех в данной среде обитания — это и быть тем языком программирования, который в этой среде сформировался.

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

M>>У тех, кто их продвигает, есть масса инструментов. Например, раздал ВУЗам IDE бесплатно или конкурс какой-нибудь устроил для студентов с призом ноутбук и т.д. А студенты — это считай новая экологическая ниша.

M>Там занята ниша. Паскалем, например (как языком созданным для обучения, и действительно долго эту нишу занимавшим).

Что значит занята? Пришёл к ректору, подарил институту пару ноутов, бутылку гавайского рома или конверт денег (в зависимости от пристрастий ректора) и можешь впаривать что угодно.

M>Собственно говоря, было бы столько денег — проблем бы не было. Дале денег преподавателям, они бы заставили студентов не только учить — но и помогать развивать новый инструмент. Только примеры OCaml и прочих показывают — этого не достаточно. Кстати, интересно — а почему этого не достаточно оказалось?

А при чём тут Ocaml? У авторов языков все баксы в партмоне влезают. Чемодан-другой как-то проблематично изыскать. Кстати, насчёт Ocaml, если бы авторы ML не выпендривались и сделали человеческий C-подобный синтаксис, то может уже давно бы смели все господствующие ныне языки.

Здравствуйте, mkizub

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

Так вот вопрос: Что же такое "грамотное" развитие и чем оно отличается от "неграмотного"?

M>Мне тяжело придумать такие маргинальные области, где прижились бы Nemerle, Scala и т.п. — слишком у них "узкая" область применимости. А вот SymADE такое вполне может. На ум сразу приходят среда разработки для малосерийных чипов, или среда разработки скриптов для игрушек — вроде Unreal или Gothic, где скрипты пользуются в полный рост, но создавать полноценную IDE разработчики не в силах (слишком дорого, и не настолько нужно). А вот в SymADE, как легко расширяемом IDE, легко подстраивающемся под DSL — запросто можно реализовать, и это будет дёшево и удобно.

M>Если у вас есть ещё идеи о "маргинальных" средах, где SymADE можно было-бы попользовать — напишите! Я сейчас пытаюсь выбрать какие-то направления. Спасибо.

Для начала было бы хорошо узнать, что такое SynADE, SOP и прочие. На примеры программ бы посмотреть. Вы бы какое-нибудь лаконичное описание-презентацию на русском языке сделали бы.

Здравствуйте, cl-user, Вы писали:

M>>Я искренне не вижу смысла в формализации обсуждаемого вопроса.

CU>Опа... А ссылки есть? Ну дай хоть что-нибудь. А то и обсуждать то нечего...

Ссылки на что? На синергетику, кибернетику и прочие етики? Гугла — главная ссылка.

Здравствуйте, machine3000, Вы писали:

M>>>Не все языки живут сами по себе.

M>>Гы. Вроде как я с этого и начал. Язык не вещь в себе, а обитает в среде различных инструментов. И эта среда не примет новый язык, только на основании того, что он лучше сам по себе. А быть "лучше" для всех в данной среде обитания — это и быть тем языком программирования, который в этой среде сформировался.

M>А я говорю, что не все языки "обитают в среде" и только. На продвижение некоторых (не надо говорить каких) тратятся баксы чемоданами. Так бы про них и не знал никто. А кто бы и узнал, так ноги бы об них вытер. Так что больше актуальна конкуренция не языков, а тех, кто их впаривает.

А. Я из первой фразы понял наборот.
Частично согласен. В том смысле, что есть объективные процессы (и они не зависят от денежной чемоданности), и есть случай (хороший менеджемент, большие деньги, просто везение). Объективные процессы работают всегда, но выбор из нескольких "похожих" технологий определяется, конечно, случаем. Для примера — после вымирания динозавров биоценоз в Евразии/Северной америке, Австралии, Южной америке формировался независимо. Везде получился разный набор зверей. Объективно лучший из них сложился в Евразиии Северной америке — это доказал "эксперимент" природы, когда южная и северная америка соединились панамским перешейком. Но это не помешало в южной америке и австралии наплодить менее крутых животных. Случай.

Но случай не работает долго. Сколько бы денег не было, но рано или поздно у людей наступит протрезвление от маркетинга. Менеджеры наслушавших hype-а про новую технологию вложат в неё деньги, и деньги пропадут — если технология объективно хреновая.

M>А при чём тут Ocaml? У авторов языков все баксы в партмоне влезают. Чемодан-другой как-то проблематично изыскать. Кстати, насчёт Ocaml, если бы авторы ML не выпендривались и сделали человеческий C-подобный синтаксис, то может уже давно бы смели все господствующие ныне языки.

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

По поводу человеческого синтаксиса для ML — это леХко. Берём SymADE, приделываем к нему онтологию (набор семантических узлов) для ML, и отображаем/редактируем в любом синтаксисе, хоть родном, хоть С-подобном. Не желаешь пропробовать?

Здравствуйте, eao197, Вы писали:

E>Так вот вопрос: Что же такое "грамотное" развитие и чем оно отличается от "неграмотного"?

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

E>Для начала было бы хорошо узнать, что такое SynADE, SOP и прочие. На примеры программ бы посмотреть. Вы бы какое-нибудь лаконичное описание-презентацию на русском языке сделали бы.

На русском есть, я его даже для RSDN подготовил, но что-то не публикуют. Может плохая статья — можете почитать http://www.symade.org/SOP_and_SymADE.doc

Вкратце, SOP — это развитие идеи Intentional Programming, где предполагается не только редактировать программу непосредственно в виде AST, но и результат компиляции будет деревом семантических узлов. В результате получится намного более мощная система, чем просто structured editor, и meta-programming на уровне исходников.
SymADE — это open-source реалиация среды разработки для SOP.

Здравствуйте, mkizub, Вы писали:

M>>>Я искренне не вижу смысла в формализации обсуждаемого вопроса.

CU>>Опа... А ссылки есть? Ну дай хоть что-нибудь. А то и обсуждать то нечего...

M>Ссылки на что? На синергетику, кибернетику и прочие етики? Гугла — главная ссылка.

Ссылки на документацию/тех. описание "парадигмы SOP".

Здравствуйте, cl-user, Вы писали:

M>>Ссылки на что?

CU>Ссылки на документацию/тех. описание "парадигмы SOP".

А. Просто мы в этой теме не SOP обсуждали, а %subj%.
У парадигмы нет тех. описания. Парадигма — это концепция, способ думать. В общем http://ru.wikipedia.org/wiki/Парадигма
А описание ты уже читал.

Здравствуйте, mkizub, Вы писали:

CU>>Ссылки на документацию/тех. описание "парадигмы SOP".

M>А. Просто мы в этой теме не SOP обсуждали, а %subj%.
M>У парадигмы нет тех. описания. Парадигма — это концепция, способ думать. В общем http://ru.wikipedia.org/wiki/Парадигма
M>А описание ты уже читал.

Даже если ООП-щину или ФП-щину начать "разворачивать" от базовых концепций к базовым понятиям — немало текста получится.

Про свои впечатления от твоей статьи я уже писал.

Пытаться на одной только идее "из семантического дерева исходников — семантическое дерево для VM" без доскональной детализации стразу делать проект — утопия. Создаётся впечатление, что все твои знания/мысли в этой области существуют тоже в виде "семантического дерева знаний" и принципиально в тексте не излагаются. Вот и не понятно: почему нельзя хотя-бы "прототипировать" эти идеи на "текстовых деревьях" (XML, лисп, да хоть форт или чёрт лысый) и попутно уже показывать что где и как [возможно] будет оптимизированно.

Причём в наборе:

— представление (ввод, изменение) дерева

— преобразование одного дерева в другое

— 'деревянный' VM

меня больше всего интересует последний пункт. Всё остальное — семечки по сравнению с этим. Опять-же, прототипирование такого VM можно было бы сделать на любом из существующих: LLVM, JVM, parrot и т.д.

Но без тех. описания как минимум последних двух частей в наборе первая для меня совсем не представляет ценности.

Ладно, это была всего лишь моя т.з.

Успехов!

Здравствуйте, cl-user, Вы писали:

CU>Даже если ООП-щину или ФП-щину начать "разворачивать" от базовых концепций к базовым понятиям — немало текста получится.

Пишем помаленьку.

CU>Пытаться на одной только идее "из семантического дерева исходников — семантическое дерево для VM" без доскональной детализации стразу делать проект — утопия. Создаётся впечатление, что все твои знания/мысли в этой области существуют тоже в виде "семантического дерева знаний" и принципиально в тексте не излагаются. Вот и не понятно: почему нельзя хотя-бы "прототипировать" эти идеи на "текстовых деревьях" (XML, лисп, да хоть форт или чёрт лысый) и попутно уже показывать что где и как [возможно] будет оптимизированно.

Уже прототипировано. SymADE работает. Но это частная реализация, может быть и другая.

CU>Причём в наборе:

CU>- представление (ввод, изменение) дерева

Про представление в той статье много написано, не понятно чего ещё.
Изменение — как в structured editors (что удобно для деклараций и DSL языков, и эргономически — меньше клавиш жать, и для освоение — всегда подсказка есть что можно вставить в данном месте). Чего у других нет — так это специального режима редактирования выражений, потому как их-то редактировать в виде дерева действительно жутко неудобно. Зато их удобно редактировать "как текст" по той причине, что используется простейшая грамматика — имена, операторы, константы. В SymADE так и сделано — при редактировании выражения оно разворачивается в последовательность символов, констант и операторов, а после редактирования собирается обратно в дерево (на основе однозначного преобразования, задаваемого приоритетами операторов — а операторы можно определять самому).

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

CU>- преобразование одного дерева в другое

Ну уж про преобразование одного дерева в другое много чего написано. Как хочешь, как умеешь — так и преобразуй. Надо — пиши генерацию узлов вручную (что позволяет делать практически всё, но жутко неудобно и сложно в написании). Для более простых случаев можно пользовать макро-процессор в виде псевдо-квотирования, в виде AOP пойнткатов и действий, да хоть в виде inline метадов. В SymADE сейчас есть а) конечно вручную изменение дерева и узлов, б) подстановка шаблонов кода (что-то вроде псевдо-квотирования) реализованная как отдельный плагин или вызываемая из других плагинов.

CU>- 'деревянный' VM

Нету ещё. Поскольку она особого смысла не имела, без наличия деревянного редактора (среды разработки), то с IDE я и начал.

CU>меня больше всего интересует последний пункт. Всё остальное — семечки по сравнению с этим. Опять-же, прототипирование такого VM можно было бы сделать на любом из существующих: LLVM, JVM, parrot и т.д.

Можно. Думал на шару раздобыть прототип — нашёл работы у http://www.ics.uci.edu/~franz/ , но они говорят — нет у нас прототипа VM.
Были-б деньги — уже давно начал делать. Собственно, когда я работал в esmertec я и хотел там сделать такую VM, но фирма решила в авантюры не пускаться и я ушёл от них

CU>Но без тех. описания как минимум последних двух частей в наборе первая для меня совсем не представляет ценности.

Заходи через пару лет, думаю к тому времени уже что-то будет.

Здравствуйте, mkizub, Вы писали:

M>Вкратце, SOP — это развитие идеи Intentional Programming, где предполагается не только редактировать программу непосредственно в виде AST, но и результат компиляции будет деревом семантических узлов. В результате получится намного более мощная система, чем просто structured editor, и meta-programming на уровне исходников.

Наиболее мощная за счёт чего?

Здравствуйте, Andrei F., Вы писали:

AF>В общем, всё сводится к одному — поддержка legacy приложений и инструментов.

"legacy" — это терминалогия из лексикона маркетлоков компаний вроде MS или IBM. Им чтобы втюхать что-то мало полезное всегда нужно пометить все что было до этого ярлыком "legacy".

Так текстовый формат метился ярлыком "legacy" тем же MS уже минимум раз 5. И что же мы видим в итоге? Линукс весь живет на тексте и в ус не дует. И сама МС в своем дотнете отказывается от реестра как бинарного хранилища в пользу текстовых файлов (ХМЛ, но не суть).

Так что оставим эти меркетологические уловки.

VD>>Толку же в хранрении бинарников я не вижу никакого. Может это и упростило бы компилятор за счет того что можно было отказаться от парсера, но не сильно. Учитывая же, что без импорта и экспорта в другие форматы все равно не обойтись (при наличии АСТ в бинарном виде), то вообще не ясно о чем собственно говорить.

AF>Нет необходимости выполнять преобразование туда<->обратно на каждый чих пользователя (со всеми вытекающими последствиями в виде дополнительных багов и затрат ресурсов).

Ну, как же нет? Пользователь же не может править бинрники? Значит любое изменение требует преборазования туда, сюда.

AF> Решарпер например отличная программа, но как же меня достали ее баги и пожирание ресурсов — это просто неописуемо.

Ну, а VS 2005 работает быстро и довольно надежно. Что это доказывает? Ничего? Ну, вот и не надо приводить подобные "доказательства".

Решарпер сложный прдукт который ишут простые смртные. Не странно, что при таком объеме фуцниональнсоти он не является самым быстрым.

AF> А если сюда добавить еще какой-нибудь диаграммер и анализатор кода (которые тоже каждый создают свое представление кода в виде AST), то вообще полная труба.

И в чем эта труба? "Диаграммер и анализатор будут читать AST. Главное, чтобы был удобный АПИ его получения. Вот у нас так и есть. Есть компилятор который позволяет загрузить проект и манипулировать АСТ.

AF>Если код парсится один раз — когда пользователь его вводит или модифицирует, а дальше все манипуляции выполняются только над AST, то это сильно упрощает создание инструментов разработчика.

Это только усложняет их, так как сужает выбор. Так инструменты могут работать и на уровне кода, и на уровне АСТ. А в твоем случае только на уровне АСТ.

Здравствуйте, VladD2, Вы писали:

VD>Решарпер сложный прдукт который ишут простые смртные. Не странно, что при таком объеме фуцниональнсоти он не является самым быстрым.

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

Здравствуйте, VladD2, Вы писали:

VD>"legacy" — это терминалогия из лексикона маркетлоков компаний вроде MS или IBM. Им чтобы втюхать что-то мало полезное всегда нужно пометить все что было до этого ярлыком "legacy".
VD>Так текстовый формат метился ярлыком "legacy" тем же MS уже минимум раз 5. И что же мы видим в итоге? Линукс весь живет на тексте и в ус не дует. И сама МС в своем дотнете отказывается от реестра как бинарного хранилища в пользу текстовых файлов (ХМЛ, но не суть).

VD>Так что оставим эти меркетологические уловки.

Ну это уже чистейшей воды демагогия началась. legacy — термин со вполне устоявшимся значением. Слово "programming" маркетоиды тоже любят, может ты и его заодно анафеме предашь?

VD>Ну, как же нет? Пользователь же не может править бинрники? Значит любое изменение требует преборазования туда, сюда.

только в очень ограниченных размерах

VD>Ну, а VS 2005 работает быстро и довольно надежно. Что это доказывает? Ничего? Ну, вот и не надо приводить подобные "доказательства".
VD>Решарпер сложный прдукт который ишут простые смртные. Не странно, что при таком объеме фуцниональнсоти он не является самым быстрым.

быстро и надежно? ха-ха три раза

VD>И в чем эта труба? "Диаграммер и анализатор будут читать AST. Главное, чтобы был удобный АПИ его получения. Вот у нас так и есть. Есть компилятор который позволяет загрузить проект и манипулировать АСТ.

"У вас" — это значит только для одного языка, да и то в глубокой бете

VD>Это только усложняет их, так как сужает выбор. Так инструменты могут работать и на уровне кода, и на уровне АСТ. А в твоем случае только на уровне АСТ.

Это кто сказал? Для поддержки legacy приложений текст никто не мешает оставить.

Здравствуйте, IT, Вы писали:

IT>Наиболее мощная за счёт чего?

За счёт того, что целое — больше суммы частей его составляющих.
Расширяемость и сложность на уровне компилятора ограничивается фиксированностью языка (байткода, нэйтивного кода и т.п.). Можно значительно повысить качество компилятора за счёт передачи ему высокоуровневой информации (напрямую, в виде дерева). И одновременно можно значительно повысить качество кода, имея расширяемый компилятор. И наоборот — никому нафиг не нужен расширяемый компилятор, если ему на вход и у него на выходе стоит нерасширяемый формат данных (синтаксис). Никому нафиг не оказались нужны просто structured editor для редактирования фиксированного текстового синтаксиса. А вместе они дают больше, чем каждый по отдельности. Точно так-же эта технология продолжается вглубь, до железа (вроде специальных GPU или настраиваемых FPGA) и вверх до дизайна программ (туда, где ныне живёт UML и пр.).