После прочтения топика "Следующий язык программирования" мне тут подумалось. Новый язык может быть создан двумя путями. Первый — из новой идеологии программирования (которая была бы ортогональна ООП, функциональному, или же являлась надмножеством их); но вряд ли мы тут сможем слуайно эту идеологию придумать или угадать, а если сможем, то новый язык будет уже на 75% готов Второй путь — добавить к возможностям существующих языков новые, которые окажутся настолько важными, что те задачи, которые сейчас решаются долго или не решаются, будут решаться очень красиво и элегантно. Так вот параллельно основному топику, где происходит непонятно что ближе к первому пути, чем ко второму, я предлагаю пойти по второму пути здесь.
Т.е. пойти от проблем. Если каждый вспомнит случай из практики, когда он упирался в ограниченность своего языка (т.е. чувствовал, что возможно более красивое решение, если бы язык позволял его сделать). Из чего станет ясно, какие фичи новый язык должен уметь,
Предлагаю принимать чисто практические задачи, с которыми вы сталкивались в практике.
Мои мысли по этому поводу. Будущее — за DSL!
Язык, который предоставит возможность создавать DSL просто, удобно и эффективно — он и станет "прорывом"
ИМХО, базовый язык должен предоставлять минимальное количество конструкций, фактически на уровне ассмеблера (только независимого от платформы — CIL, например). Однако, там должна быть возможность создавать и расширять свои языковые конструкции, а также группировать эти конструкции в библиотеки, которые можно подключать по мере необходимости.
Хотите прямой доступ к памяти? Подключайте и пользуйтесь. Хотите сборщик мусора? Аналогично. Функциональный стиль — аналогично.
При этом, что очень важно, необходимы средства управлять зависимостями между такими библиотеками DSL, а также правами доступа к ним. Например, необходимо иметь возможность установить, что кодерам запрещено использовать Dsl.RawMemoryAccess
Здравствуйте, Дарней, Вы писали:
Кё>>Я имел ввиду не это, а отсутствие необходимой выразительности в языке.
Д>Я думаю, намного лучше, когда есть возможность добавлять необходимую выразительность самому
По-моему это из разрада фантастики. Либо это Лисп, что уже неудовлетворительно из-за трудного для восприятия синтаксиса.
Здравствуйте, Дарней, Вы писали:
Д>Мои мысли по этому поводу. Будущее — за DSL! Д>Язык, который предоставит возможность создавать DSL просто, удобно и эффективно — он и станет "прорывом"
Боюсь только, что динамическая природа Ruby не позволит ему стать мейнстримом. Все же глобальный отказ от статической типизации даже для меня пока выглядит экстремизмом (хотя я все больше и больше попадаю под влияние Duck Typing-а).
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Кодёнок, Вы писали:
Кё>>>Я имел ввиду не это, а отсутствие необходимой выразительности в языке.
Д>>Я думаю, намного лучше, когда есть возможность добавлять необходимую выразительность самому
Кё>По-моему это из разрада фантастики.
Ты думаешь?
dir.each { |filename| block } => dir
Calls the block once for each entry in this directory, passing the filename of each entry as a parameter to the block.
d = Dir.new("testdir")
d.each {|x| puts "Got #{x}" }
Здравствуйте, Кодёнок, Вы писали:
Кё>По-моему это из разрада фантастики. Либо это Лисп, что уже неудовлетворительно из-за трудного для восприятия синтаксиса.
Я конечно знаю, что ничего подобного сейчас нет. Но хочется
Что касается синтаксиса, то возможность его кастомизации — это тоже очень важный аспект. Имея полностью настраиваемый язык, можно будет навсегда забыть про споры типа "= vs :=" и "begin vs {"
Правда, сам код в таком случае надо будет хранить не в виде текста, а в виде предварительного распарсенного промежуточного представления. В этом случае, кстати, намного упрощается создание средств рефакторинга и визуализации, контроль изменений и просмотр истории, и т.д.
В общем, plain text must die
ИМХО следующим будет, действительно, не язык, а некая "безъязыковая" технология, кторая позволит без ощутимых накладных расходов испольщовать наиболее удобный для каждого конкретного случая синтаксис. Т.е. да, DSL.
Здравствуйте, mihoshi, Вы писали:
M>ИМХО следующим будет, действительно, не язык, а некая "безъязыковая" технология, кторая позволит без ощутимых накладных расходов испольщовать наиболее удобный для каждого конкретного случая синтаксис. Т.е. да, DSL.
Да какая разница В С++ если создать набор типов и переопределить их операции, то тоже получиться некий DSL. Например, для операций над матрицами. Теоретически, расширяя набор перегружаемых операций и даже позволяя вводить свои постфиксные, инфиксные и префиксные операции, можно получить язык, в котором можно создать любой удобный DSL.
Я не против, чтобы мы сейчас его придумали; но по-моему ничего не выйдет с нуля сейчас что-то путнее сделать. Для начала может просто попытаться преодолеть конкретные ограничения конкретные языков? А там уже сможем обобщить и тогда оно станет более реально.
Т.е. просто сказать "безъязыковая технология" мало, надо же конкретно уточнить все её детали, прежде чем она станет возможной. Вот лучше каждую деталь продумать, и тогда хотя бы станет ясно, что в новом языке точно должно быть и чего точно не должно.
Здравствуйте, eao197, Вы писали:
Д>>>Я думаю, намного лучше, когда есть возможность добавлять необходимую выразительность самому
E>Ты думаешь? E>dir.each { |filename| block } => dir E>Calls the block once for each entry in this directory, passing the filename of each entry as a parameter to the block.
Я не совсем это имел ввиду в примере про FindFirst/FindNext, но это приемлемая альтернатива. Я имел ввиду автоматическую генерацию объектов-генераторов (термин из Питона 2.4). Т.е. ты пишешь обычный код, но он компилируется по-особому, сохраняя состояние не в стеке (как это делает обычный код), а в некоторой структуре данных.
Очень удобно. В С++ я могу написать объект-итератор для FindFirstFile/FindNextFile, но это требует много нудной работы, тогда как всего лишь дополнительная фича в языке позволила бы сделать это _обычным_, естественным кодом (циклом while).
А из разряда фантастики — это язык, где можно добавить необходимую выразительность самому. Как например в Руби добавить возможность одной инструкцией вставить во все функции модуля одинаковый код проглога/эпилога, или определить DSL на Руби, абсолютно эквивалетный по синтаксису Лиспу. Это возможно? По-моему, в общем случае это невозможно вообще.
Здравствуйте, Кодёнок, Вы писали:
Кё>Я не совсем это имел ввиду в примере про FindFirst/FindNext, но это приемлемая альтернатива. Я имел ввиду автоматическую генерацию объектов-генераторов (термин из Питона 2.4). Т.е. ты пишешь обычный код, но он компилируется по-особому, сохраняя состояние не в стеке (как это делает обычный код), а в некоторой структуре данных.
Кё>Очень удобно. В С++ я могу написать объект-итератор для FindFirstFile/FindNextFile, но это требует много нудной работы, тогда как всего лишь дополнительная фича в языке позволила бы сделать это _обычным_, естественным кодом (циклом while).
В C++ это действительно так, в Ruby на несколько порядков проще.
Кё>А из разряда фантастики — это язык, где можно добавить необходимую выразительность самому. Как например в Руби добавить возможность одной инструкцией вставить во все функции модуля одинаковый код проглога/эпилога,
Одной инструкцией вряд-ли, а вот несколькими -- возможно.
module Kernel
alias :intercepted_require :requiredef require( a_module )
puts "starting requiring #{a_module}"
intercepted_require a_module
puts "finishing requiring #{a_module}"
end
end
require "rubygems"
require "optparse"
puts "Done!"
Здесь просто переопределяется стандартный метод Kernel#require, с помощью которого осуществляется подгрузка модулей в Ruby.
Кё> или определить DSL на Руби, абсолютно эквивалетный по синтаксису Лиспу. Это возможно? По-моему, в общем случае это невозможно вообще.
По-моему, это и не нужно. Хочется программировать на Лиспе, программируй на Лиспе. А попытки притянуть Лисп в C++ вот к чему приводят: Lisp на C++
Имхо, DSL должен не менять синтаксис основного языка, а позволять писать на том же языке, но на более высоком уровне абстракции.
Например:
directory "testdata"
file "testdata" => ["otherdata"]
file "testdata" do
cp Dir["standard_data/*.data"], "testdata"
end
это одновременно и текст DSL Rake, и, в тоже самое время, абсолютно родной Ruby код. И если на более высоком уровне абстракции мне нужно выполнить какую-то низкоуровневую операцию, то я могу это сделать:
file "prog" => ["a.o", "b.o"] do |t|
sh "cc -o #{t.name} #{t.prerequisites.join(' ')}"
end
(здесь t.prerequisites.join -- это обращение к методу Array#join, т.е. мы опускаемся с уровня DSL на уровень обычного Ruby кода, но делаем это совершенно естественным образом).
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Кодёнок, Вы писали:
Кё>Здравствуйте, Дарней, Вы писали:
Кё>>>Я имел ввиду не это, а отсутствие необходимой выразительности в языке.
Д>>Я думаю, намного лучше, когда есть возможность добавлять необходимую выразительность самому
Кё>По-моему это из разрада фантастики. Либо это Лисп, что уже неудовлетворительно из-за трудного для восприятия синтаксиса.
Здравствуйте, Кодёнок, Вы писали:
Кё>И компилятор автоматически сделает код, сохраняющий своё состояние между "yield-ами".
Ну, вот и подумай, что лучше, если ты будешь иметь возможность расширить язык этим yield и соовтевтующей генерацией кода, или когда ты будешь вынужден ждать когда в твой любимый ХХ добавят такую фичу?
Вот в C# 2.0 такую фичу добавили, но я бы был в сто раз более рад если в него добавили нечто что позволяло бы мне самому описывать синтаксические конструкции которые я могу бы во время компиляции превращать в некую реализацию паттерна.
Ведь компилятор C# 2.0 просто создает класс в котором находится реализация ДКА соотвествющая коду из итератора. Так дайте мне возможность сделать это сомому!
И главно, наплевать на Вирта и растереть. Путь он кому угодно объясняет, что "синтаксис должен быть простым и не изменяемым". Я уверен, что синтаксис должен быть игбким и удобным. Я уверен, что чем проще описывается решение, тем проще его будет развивать и поддерживать. И ДСЛ на базе некого механизма описания синтаксиса + метапрограммирование позволило бы свернуть горы.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
Кё>>И компилятор автоматически сделает код, сохраняющий своё состояние между "yield-ами".
VD>Ну, вот и подумай, что лучше, если ты будешь иметь возможность расширить язык этим yield и соовтевтующей генерацией кода, или когда ты будешь вынужден ждать когда в твой любимый ХХ добавят такую фичу?
Я тоже за это, но пусть хоть кто-нибудь хоть какой-нибудь реальный пример приведёт, чтобы убедиться, что это возможно Ну например? Что надо добавить в C#, чтобы он научился делать объекты-генераторы из обычного кода, при условии, что это специально не предусмотрено? Т.е. возможности расширения настолько общие, что позволяют сделать yield, но не созданные специально для него?
Ну разумеется, это C++ после очередного релиза стандарта (это ответ на тему топика)
Кё>Т.е. пойти от проблем. Если каждый вспомнит случай из практики, когда он упирался в ограниченность своего языка (т.е. чувствовал, что возможно более красивое решение, если бы язык позволял его сделать). Из чего станет ясно, какие фичи новый язык должен уметь,
Ни разу не упирался в ограниченность своего языка
И вообще, зачем выбрасывать то, что реально работает?
Здравствуйте, LeeMouse, Вы писали:
LM>Ни разу не упирался в ограниченность своего языка LM>И вообще, зачем выбрасывать то, что реально работает?
Что работает? Работают только люди, а инструменты не работают. Инструмент "ассемблер x86" тоже реально "работает" и позволяет написать 100% программ, которые пишутся на высокоуровневых языках, но реально сделать с его помощью удаётся многократно меньше.
Здравствуйте, Кодёнок, Вы писали:
Кё>Я тоже за это, но пусть хоть кто-нибудь хоть какой-нибудь реальный пример приведёт, чтобы убедиться, что это возможно Ну например? Что надо добавить в C#, чтобы он научился делать объекты-генераторы из обычного кода, при условии, что это специально не предусмотрено? Т.е. возможности расширения настолько общие, что позволяют сделать yield, но не созданные специально для него?
Нужно добавить некий макрос который встретив например:
yield_return(x);
поймет, что нужно преобразовать это дел в конечный автомат.
Если появится возмжность еще и новые ключевые слова добавлять, так это вообще будет здорово. Но я и так буду счаслив.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Кодёнок, Вы писали:
Кё>>>И компилятор автоматически сделает код, сохраняющий своё состояние между "yield-ами".
VD>>Ну, вот и подумай, что лучше, если ты будешь иметь возможность расширить язык этим yield и соовтевтующей генерацией кода, или когда ты будешь вынужден ждать когда в твой любимый ХХ добавят такую фичу?
Кё>Я тоже за это, но пусть хоть кто-нибудь хоть какой-нибудь реальный пример приведёт, чтобы убедиться, что это возможно Ну например?
Дарней,
> Правда, сам код в таком случае надо будет хранить не в виде текста, а в виде предварительного распарсенного промежуточного представления. В этом случае, кстати, намного упрощается создание средств рефакторинга и визуализации, контроль изменений и просмотр истории, и т.д.
Имхо, наоборот, все значительно усложняется: сейчас есть масса средств, работающих с plain text. В случае выбора какого-то своего представления нужно будет проделать очень много работы, чтобы это представление было "понятно" имеющимся инструментам, или же переписать все нужные инструменты на всех нужных платформах (поиск по файлам, diff, merge, VCS и т.п.).
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Имхо, наоборот, все значительно усложняется: сейчас есть масса средств, работающих с plain text. В случае выбора какого-то своего представления нужно будет проделать очень много работы, чтобы это представление было "понятно" имеющимся инструментам, или же переписать все нужные инструменты на всех нужных платформах (поиск по файлам, diff, merge, VCS и т.п.).
Да, конечно
Но преимущества перевешивают затраты, ИМХО
Здравствуйте, mihoshi, Вы писали:
M>ИМХО следующим будет, действительно, не язык, а некая "безъязыковая" технология, кторая позволит без ощутимых накладных расходов испольщовать наиболее удобный для каждого конкретного случая синтаксис. Т.е. да, DSL.
Здравствуйте, Кодёнок, Вы писали:
Кё>Предлагаю принимать чисто практические задачи, с которыми вы сталкивались в практике.
Немножко пользовал 2005 бету. Удобно. И думаю, что до появления нового языка мы увидим ещё более удобную IDE, когда визарды ещё больше войдут в написание кода. Даже более того, не только в написание, но и в редактирование. Увеличится объем текста, с которым будут работать визарды. ...
По поводу же языка думаю также сначала будет увеличение возможностей существующих:
— если некоторая пара комманд используется часто вместе, то пусть будет одна команда (старые остаются или изменяются);
— стандартизация наименований до такой степени, что входные и выходные параметры заложены в наименовании (например GetValue) и как следствие, создание "глобального" фреймворка;
— и вообще, избавление от типов:
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, Кодёнок, Вы писали:
Кё>>Я имел ввиду не это, а отсутствие необходимой выразительности в языке.
Д>Я думаю, намного лучше, когда есть возможность добавлять необходимую выразительность самому
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, Кодёнок, Вы писали:
Кё>>По-моему это из разрада фантастики. Либо это Лисп, что уже неудовлетворительно из-за трудного для восприятия синтаксиса.
Д>В общем, plain text must die
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, Mystic, Вы писали:
M>>Опять литературное прогаммирование
Д>в смысле?
В литературном программировании по исходному описанию программы (web) генерируется текст для компилятора (pas, c или cpp, абсолютно нечитаемый) и TeX-файл описания программы. Потом из TeX-файла нетрудно получить PDF. Эта идея на уровне начала 1980-х годов, тогда же вышли первые статьи Д. Кнута о литературном программировании. Там же были включены примитивные средства управления листингом программы, добавления к языку новых структур, ... Если бы на современном уровне кто-то попытался реинкарнировать эту идею...
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, Mystic, Вы писали:
M>>Частично это есть в WEB и CWEB. Только не пошло
Д>а где почитать можно?
Их сайт www.literateprogramming.com, там же есть статьи Д. Кнута. У меня есть порты TANGLE и WEAVE на Delphi, исходники TeX, ... Повторяю, все на уровне 1980-х годов
Здравствуйте, Mystic, Вы писали:
M>В литературном программировании по исходному описанию программы (web) генерируется текст для компилятора (pas, c или cpp, абсолютно нечитаемый) и TeX-файл описания программы. Потом из TeX-файла нетрудно получить PDF. Эта идея на уровне начала 1980-х годов, тогда же вышли первые статьи Д. Кнута о литературном программировании. Там же были включены примитивные средства управления листингом программы, добавления к языку новых структур, ... Если бы на современном уровне кто-то попытался реинкарнировать эту идею...
Желающих, мне кажется — вагон и маленькая тележка. Похоже, сейчас эта идея просто витает в воздухе.
А вообще идея правильная, сам давно мечтаю
Здравствуйте, Mystic, Вы писали:
M>Их сайт www.literateprogramming.com, там же есть статьи Д. Кнута. У меня есть порты TANGLE и WEAVE на Delphi, исходники TeX, ... Повторяю, все на уровне 1980-х годов
похоже, сейчас начался новый виток спирали и к этой идее начали возвращаться. Глядишь, и получится что-нибудь дельное. Я и сам пытаюсь, по мере своих скромных сил, хоть что-нибудь реализовать.
Здравствуйте, Дарней, Вы писали:
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>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Второй путь — добавить к возможностям существующих языков новые, которые окажутся настолько важными, что те задачи, которые сейчас решаются долго или не решаются, будут решаться очень красиво и элегантно. Так вот параллельно основному топику, где происходит непонятно что 
