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

LVV>> которая удобна именно программистам.

ME>а вот еще че забыл спросить -- грамматика для перевода дерева/графа в текстовое представление проверяется на однозначность? т.е. может возникнуть такая ситуация, что два *разных* графа выливаются в один и тот же текст?
Проверяли, но поскольку нет пока обратной операции текст->модель, то еще будем проверять.
Кроме того, выделили процедурное ядро Додиеза и Оберона — оно одинаковое с семантической точки зрения.
Взяли грамматики этих языков и сравнили.
И теперь у нас одной кнопочкой на экране хочешь — Додиез, а хочешь — Оберон. В процедурной части, естественно.
Тут еще работать и работать. Но к сентябрю хотим первую версию запустить. Прямо в классах.

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

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

LVV>>А сама структура конструкции оператора редактирования не требует.
LVV>>Он добавляется в модель одной клавишей.

D>Дык это и щас есть. Code snippets называется, что ли... Один хрен не пользуюсь — лениво запоминать горячую клавишу и настраивать удобные мне шаблоны с удобным мне форматированием.
Ну, мы тоже на сниппетах остановились.
LVV>>Одной же и удаляется.
D>Гы. Я так понимаю, не дай бог нажать delete под словом "class".
Ну вы батенька совсем уж нас за лохов принимаете...

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

W>Мне так кажется, что надо не обсуждать что сделают другие, а что мы сделаем в том момент когда все зашло в тупик, самый момент предложить что-то новое.
Мы и делаем. Сами. Для себя.
W>Но для начала надо понять что плохо.
Что плохо для преподов — это я могу МНОГО написать. Что плохо для студентов — тут индивидуально очень. Один пон7имает влет. Другому надо 100500 раз повторить.
W>А плохо то что так и не создан язык, подобный математическому языку. Языку без ифов, языку без двоичной логики. Ну если хотите, для затравки/обьяснения — языку у которого иф как бы срабатывает на 0.5 То есть если уловие уже близко к истине он уже начинает выполняться.
W> Кстати кто будет участвовать в разработке?
В Вашей команде? Мы не будем, у нас свои разработки.

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

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

W>Мне так кажется, что надо не обсуждать что сделают другие, а что мы сделаем в том момент когда все зашло в тупик, самый момент предложить что-то новое.

W>Но для начала надо понять что плохо.

W>А плохо то что так и не создан язык, подобный математическому языку. Языку без ифов, языку без двоичной логики. Ну если хотите, для затравки/обьяснения — языку у которого иф как бы срабатывает на 0.5 То есть если уловие уже близко к истине он уже начинает выполняться.



Это, по-вашему, не математика, да?
Да и двоичная логика с чего вдруг из математики пропала?

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

W> Кстати кто будет участвовать в разработке?

Да, вот еще, что — природа создала свой язык программирования, точнее архитектуру, мне кажется, сейчас самое время использовать ее наработки. Я об ДНК/РНК.

И кстати повторю, чтобы не показалось что это стеб — наберется человек 20 настоящих профессионалов? Причем именно супер-профессионалов, с амбициями на прорыв?

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

К>

К>Это, по-вашему, не математика, да?
К>Да и двоичная логика с чего вдруг из математики пропала?

Не хочу спорить, мне кажется, что Вы не поняли сути. И в этом нет ничего плохого. Я к тому что это я дурак плохо объяснил.

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

LVV>Первая часть компилятора физически отсутствует — фактически требуют анализа только выражения.
LVV>Но на экране — текст, который читает человек.

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

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

Из Архангельска не берем.

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

W>А плохо то что так и не создан язык, подобный математическому языку. Языку без ифов, языку без двоичной логики.
И не будет создан. имеется ввиду широко применяемый, чтобы в 20ку TIOBE попасть.

Потому что символьная запись в математике применяется для ИЗВЕСТНЫХ закономерностей.
А компьютерные программы обрабатывают НЕИЗВЕСТНЫЕ задачи. Например — мы не знаем заранее в каком порядке и в каком месте экрана пользователь княпнет.
Имеем — противоположные условия.

Второе принципиальное отличие.
Компьютерные программы вобщем-то занимаются преобразованием информации, из одного вида в другой. Язык программирования позволяет записать правила этого преобразования. И правила эти в общем случае — произвольны. Нет на них никакого "закона".
Математическая же запись предназначена для записи логических соответствий между сущностями. Причем мы вначале однозначно должны определить эти сущности.
И эти две задачи ИМХО ортогональны. Но за счет специализации на ЯП легче решать первые задачи, а языком математики вторые.

Так что ничего случайного, что такой язык не был создан ранее. Он не годится для практического программирования.

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

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

LVV>>Первая часть компилятора физически отсутствует — фактически требуют анализа только выражения.
LVV>>Но на экране — текст, который читает человек.

IT>Где-то в середине 90-х был подобный редактор для модулы, если не ошибаюсь. Всё проверял, всё контролировал, не давал делать ошибок и везде старался как мог. Смотрелось очень круто. Выкинули его через неделю и не потому что он плохо делал свою работу, а как раз наоборот слишком хорошо. Смотреть на него, конечно, было прикольно, но работать в нём было невозможно по одной простой причине. Некомпилируемый, разваленный и разрезанный на куски код — это перманентное состояние программы над которой в данный момент трудится программис. И каким образом он перейдёт из одного рабочего состояния программы в другое известно только ему одному.
Вот это и пора сломать в 21-м веке...
Хватит кустарничать! Пора переходить к промышленному программированию.
Интересный фактец. Пацан, которые пишет сам семантический редактор, признался.
Он для проверки интерпретатора пишет в нем тестовые проги — довольно много.
А редактор делает исключительно структурный текст.
И пацан заметил за собой, что в студии на шарпе он стал писать структурный текст.
И что смешно. По его собственному признанию проги стали получаться проще, понятней и с меньшим количеством ошибок.
И это 4 курс, вроде все дурные привычки уже в крови.
А вот получил правильный инструмент — и привычки стали меняться...

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

ME>теперь часть Б -- с чем я согласен

ME>это язык для создания запросов к исходному коду и для трансформации исходного кода

ME>что касается нетекстового и нефайлового хранения -- идея 50% на 50%; хотя мне честно говоря не хватает текстового представления языка, нетекстовое потребует затрат по адаптации к нему vcs
Универсально удобного для всех случаев представления и быть не может. Потому логичнее иметь несколько представлений. У меня их несколько.. Тектовый, теговый, типа конструктора (графический), в табличном виде (базы данных), да еще и связи (типа UML) И классы объекты оттуда же. Такое стало возможным именно из-за единства формата всего. И файлов тоже. Расширения просто перестали существовать. Это свойство документа как загружаемой (передаваемой) единицы..

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

Я бы заметил, что файловая древовидная модель — это анахронизм, хотя и очень удачный. В целом операционки уже давно пытаются прятать тот факт, что есть какие-то файлы. "Установленные программы", "Медиабиблиотека", "Плэйлист" — шаг в правильном направлении. Я не знаю, что будет в будущем, мб что-то ближе к БД или тэгам.

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

LVV>Редактирует. Но не весь. Ключевые слова нафиг редактировать.
LVV>Имена, константы, выражения — это требует редактирования ручного. А сама структура конструкции оператора редактирования не требует.
Да, правда, что-ли?
Возьмем немеле. И посмотрим на конструкцию foreach
Самый простой вариант

foreach (item in collection)
{
}

номер элемента

foreach (item in collection with i)
{
}

паттерны в теле цикла

foreach (item in collection)
{
    | SomeItem => ...
    | SomeElseItem => ...
}

выберем из коллекции только то, что является SomeItem

foreach (item is SomeItem in collection)
{
}

А теперь представь, сколько конструкций получится, если учесть, что это все можно комбинировать.
И сами паттерны могут быть весьма кучерявыми.

Возьмём другой пример.
Это не окончательный вариант синтаксиса для парсера над которым я работаю.
По этому описанию будет построен динамически расширяемый парсер.
Пример динамической расширяемости. Ага. Прямо во время разбора текста, встретив определенную конструкцию парсер загружает из внешней длл новые правила.

Вот пример попроще.

    using IncParser;
    using NumParser;

    any = ['\u0000'..'\uFFFF'];
    s : void = ' '*;

    [StartRule]
    start : ExprAst = s expr !any;

    [StartRule]
    expr : ExprAst;

    [Ast(l, expr, r)] rounds is expr = '('s expr ')'s;
    [Ast(l, expr, r)] seq is expr = '{'s expr* '}'s;

    [Ast(num)]        num is expr = number s;

    [Ast(op, expr)]   neg is expr = '-'s expr : 100;

    [Ast(op, expr)]   prefixDec is expr = "--"s expr : 200;
    [Ast(expr, op)]   postfixDec is expr = expr : 200 "--"s;

    [Ast(l, op, r)]   add is expr = expr : 10 '+'s expr : 10;
    [Ast(l, op, r)]   sub is expr = expr : 10 '-'s expr : 10;
    [Ast(l, op, r)]   mul is expr = expr : 20 '*'s expr : 20;
    [Ast(l, op, r)]   div is expr = expr : 20 '/'s expr : 20;
    [Ast(l, op, r)]   mod is expr = expr : 20 '%'s expr : 20;
    [Ast(l, op, r)]   pow is expr = expr : 31 '^'s expr : 30;

Как видишь так называемые "конструкции" отсутствуют чуть менее чем полностью.

LVV>Он добавляется в модель одной клавишей. Одной же и удаляется.
Автокомплит для языковых конструкций сделать не проблема.

LVV>В смысле IntelliJ ?
В смысле: http://www.jetbrains.com/mps/
Поставь и посмотри. И своему орлу покажи. Пусть поймет, что велосипед делает.

LVV>В смысле IntelliJ ?

у нас все точно (с) робот в ответ громозеке

именно MPS

LVV>Импорт — это естественно будет. Но задача не первоочередная.

у них емнип уже че-то вроде импорта было, типа вставки из clipboard

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

LVV>http://ajc.su/koding/budushhee-programmirovaniya/
LVV>

LVV>[Автор оригинального текста — Paul Chiusano, программист, работает в Capital IQ, пишет преимущественно на Scala. Один из разработчиков библиотеки scalaz — прим. пер.]

Исчо один!!!
Невозможен универсальный DSL для всех программ. Теорема Геделя уже давно вещь сколько не математическая, а филосовская и доказанная на практике. Для подобных программ нужно просто отменить конкуренцию, и заставить пользователей покупать не то что они хотят, а то что им зают. А пока приходится менять уровни абстракции от уровня "Нарисуем форму", вплоть до хака переопределения функций в системных dll.
Автор утверждает, что мы уменьшим повторяемость. О каком уменьшении можно говорить, если: разработчик обычно пишет велосипеды не только на чужие модули, но и даже на уровне апи. То что надо знать еще до начала разработки. Автор выступает за увеличение сложности и неуправляемости типов. Флаг ему в руки... Точнее в культяпки, поскольку такие руки надо рубить. С чем нужно бороться? Может все таки бороться со сложностью?
Как сидели над вопросами 60-ых, как уменьшить нам сложность набора процедур. Так и сидят. Что касается уменьшения сложности, многомодульности, принципа разделяй и властвую — ноль.

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

LVV>>В смысле IntelliJ ?
WH>В смысле: http://www.jetbrains.com/mps/
WH>Поставь и посмотри. И своему орлу покажи. Пусть поймет, что велосипед делает.
1. Спасибо за информацию. Состыкую пацана — поговорите поглубже. Он информацию собирает отовсюду.
2. Мы делаем в первую очередь обучающую среду.
В ней должен быть инструмент для препода по оценке действий студента.
Основная идея именно в этом, а не в обеспечении возможности писание мегабайтных программ.
Встраивать подобный инструмент в существующие — слишком геморно и не интересно.
К тому же — опыт проектирования, разработки и рефакторинга такого большого продукта гораздо более полезен, чем ковыряние в чужой работе.

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


LVV>>В смысле IntelliJ ?

ME>у нас все точно (с) робот в ответ громозеке

ME>именно MPS

LVV>>Импорт — это естественно будет. Но задача не первоочередная.

ME>у них емнип уже че-то вроде импорта было, типа вставки из clipboard
Ну, это и у нас есть... Прямо уже сейчас...

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

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

L>>Изменения в программировании происходят,когда назревает необходимость. Так было с С++ и Java. На данный момент, контроль над мейнстримными языками осуществляют те же компании, что и создают веяния в мире софта и железа. Так получается замкнутный круг — девайс->технология<->язык.
LVV>Вот у нас (лично у нас в Астрахани) и назрела необходимость.
Речь шла о глобальных веяниях, вроде GUI, кросс-платформенности, вэб-приложений, фреймворков. За каждым стоит свой язык. А у вас в Астрахани что намечается, если не секрет?

L>>Лично я За — изменения самого образа программирования в сторону визуальности. Автор прав в том, что потеря продуктивности из-за кода в тексте, остается за пределами радаров программиста.
LVV>Нет. Мы — программисты. И должны сами сделать такой инструмент, который НАМ удобен.
LVV>Как в свое время сделали юникс — систему, которая удобна именно программистам.

НАМ удобен=нам привили=мы привыкли. Вспоминается Форд: "если бы я слушал что говорят люди, то они до сих пор бы ездили на повозках"
Однако...вопрос этого извечного "фии" на новые фиичи у коллег — это да.

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

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

L>>Лично я За — изменения самого образа программирования в сторону визуальности. Автор прав в том, что потеря продуктивности из-за кода в тексте, остается за пределами радаров программиста.

D>Попыток уйти от этого было дохрена и больше. И обсуждений причин гиблости затеи здесь тоже было дохрена и больше. Вот из последнего, где я участвовал.

Автор: dimgel
Дата: 21.04.11

Я вот глобальных попыток не видел. Пример приведете? Чтобы например как тот же Делфи в свое время ахнул. Так что все впереди. Как автор написал — визуальных инструмент должен быть значительно лучше текстового аналога. Для кого-то в vim'e на Сях — лучше всего до сих пор.

S>Компьютерные программы вобщем-то занимаются преобразованием информации, из одного вида в другой. Язык программирования позволяет записать правила этого преобразования. И правила эти в общем случае — произвольны. Нет на них никакого "закона".
S>Математическая же запись предназначена для записи логических соответствий между сущностями. Причем мы вначале однозначно должны определить эти сущности.
S>И эти две задачи ИМХО ортогональны. Но за счет специализации на ЯП легче решать первые задачи, а языком математики вторые.

С другой строны, информация A — это одни мат правила, информация B — это друние мат. правила, а программа между ними — это некое B = (g o f)(A)