Здравствуйте, VladD2, Вы писали:
Все поскипано.
Компилятор в своем классическом виде — это устаревшая концепция.
ДОСТАЛО в IDE набирать программу посимвольно!
Нуж на просто другая IDE (редактор кода, конечно), заточенная под язык программирования. Редактор должен оперировать конструкциями языка а не символами. Простой пример — по клавише сразу появляется заготовка оператора for со всеми скобками b точками с запятой. Редактор ДОПУСКАЕТ символьный ввод ТОЛЬКО в нужных местах. Программист просто не сможет изменить ключевое слово, стереть скобку и т.д.
Отталкиваться надо от семантики языка — почитайте и Страуструпа о том же в Дизайн и эволюция.
Соответственно редактор сразу работает с внутренним представлением программы (синтаксчески-семантичекой конструкцией программы). О, только что идея пришла в голову, что внутренним представлением может быть IL!!
Таким образом, при таком редакторе нужен будет только генератор кода. Парсер и лексер — в принципе не нужны! В том классическом виде, как они сейчас понимаются. Особенно лексер ( в смысле сканер). Хотя лекго может быть выполнена обратный перевод в текст (для совместимости).
Естественно, редактор должен обладать полной информацией по синтаксису и семантике языка.
Вокруг такого редактора и отладчик легче строить и профайлер.
Мои студенты пытались даже обобщить это дело на класс процедурных языков.

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

LVV>Нуж на просто другая IDE (редактор кода, конечно), заточенная под язык программирования.
LVV>Редактор должен оперировать конструкциями языка а не символами. Простой пример — по клавише сразу появляется заготовка оператора for со всеми скобками b точками с запятой.

Сразу вспомнился ZX Spectrum.

Опять ночью будут кошмары сниться...

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

LVV>>Нуж на просто другая IDE (редактор кода, конечно), заточенная под язык программирования.
LVV>>Редактор должен оперировать конструкциями языка а не символами. Простой пример — по клавише сразу появляется заготовка оператора for со всеми скобками b точками с запятой.
A>Сразу вспомнился ZX Spectrum.
Бог миловал!
A>Опять ночью будут кошмары сниться...
Почему?

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

LVV>Здравствуйте, VladD2, Вы писали:
LVV>Все поскипано.
LVV>Компилятор в своем классическом виде — это устаревшая концепция.
LVV>ДОСТАЛО в IDE набирать программу посимвольно!
Сразу же спектрумовский BASIC вспоминается...

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

LVV>Нуж на просто другая IDE (редактор кода, конечно), заточенная под язык программирования. Редактор должен оперировать конструкциями языка а не символами. Простой пример — по клавише сразу появляется заготовка оператора for со всеми скобками b точками с запятой.

Visual Assist смотрел? Как раз про то, что ты говоришь. Даже в новой студии такого не воссоздали.

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

M>Visual Assist смотрел? Как раз про то, что ты говоришь. Даже в новой студии такого не воссоздали.
Ну, идея-то в воздухе витает!
Но VA не смотрел. Где и как взять? Регистрироваться надо обязательно?
А то компилеры intelовские только через обязательную регистрацию нужно делать.
А там столько писать — прям не знаю

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

M>Visual Assist смотрел? Как раз про то, что ты говоришь. Даже в новой студии такого не воссоздали.

ИМХО ты несколько не понял. Мне кажется LaptevVV имел ввиду другое. VA действует как раз на уровне символов редактора, просто предоставляя в т.ч. по необходимости удобные шаблонные заготовки. Речь же щла об "интеграции" части языкового процессора в редактор.

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

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

M>>Visual Assist смотрел? Как раз про то, что ты говоришь. Даже в новой студии такого не воссоздали.

D_S>ИМХО ты несколько не понял. Мне кажется LaptevVV имел ввиду другое. VA действует как раз на уровне символов редактора, просто предоставляя в т.ч. по необходимости удобные шаблонные заготовки. Речь же щла об "интеграции" части языкового процессора в редактор.

Я понял. Идея с "жесткими" шаблонами не всегда удобна.

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

M>Я понял. Идея с "жесткими" шаблонами не всегда удобна.

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

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

A>>Опять ночью будут кошмары сниться...
LVV>Почему?

Це я шуткую.

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

M>>Visual Assist смотрел? Как раз про то, что ты говоришь. Даже в новой студии такого не воссоздали.

D_S>ИМХО ты несколько не понял. Мне кажется LaptevVV имел ввиду другое. VA действует как раз на уровне символов редактора, просто предоставляя в т.ч. по необходимости удобные шаблонные заготовки. Речь же щла об "интеграции" части языкового процессора в редактор.
Именно так!!!
TEMC еще в турбо-системах был сделан. Так это ж простой текствый макрос — без проверки синтаксиса и тем более, без соответствующего представления во внутреннем формате.
Потом этот текст, какой-бы он правильный не был: лексится и парсится, хотя это уже не требуется!

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

LVV>Здравствуйте, VladD2, Вы писали:
LVV>Все поскипано.
LVV>Компилятор в своем классическом виде — это устаревшая концепция.
LVV>ДОСТАЛО в IDE набирать программу посимвольно!
LVV>Нуж на просто другая IDE (редактор кода, конечно), заточенная под язык программирования. Редактор должен оперировать конструкциями языка а не символами. Простой пример — по клавише сразу появляется заготовка оператора for со всеми скобками b точками с запятой. Редактор ДОПУСКАЕТ символьный ввод ТОЛЬКО в нужных местах. Программист просто не сможет изменить ключевое слово, стереть скобку и т.д.
LVV>Отталкиваться надо от семантики языка — почитайте и Страуструпа о том же в Дизайн и эволюция.
LVV>Соответственно редактор сразу работает с внутренним представлением программы (синтаксчески-семантичекой конструкцией программы). О, только что идея пришла в голову, что внутренним представлением может быть IL!!
LVV>Таким образом, при таком редакторе нужен будет только генератор кода. Парсер и лексер — в принципе не нужны! В том классическом виде, как они сейчас понимаются. Особенно лексер ( в смысле сканер). Хотя лекго может быть выполнена обратный перевод в текст (для совместимости).
LVV>Естественно, редактор должен обладать полной информацией по синтаксису и семантике языка.
LVV>Вокруг такого редактора и отладчик легче строить и профайлер.
LVV>Мои студенты пытались даже обобщить это дело на класс процедурных языков.

что-то так ZX-спектрумаи повеяло...

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

LVV>Все поскипано.
LVV>Компилятор в своем классическом виде — это устаревшая концепция.
LVV>ДОСТАЛО в IDE набирать программу посимвольно!
LVV>Нуж на просто другая IDE (редактор кода, конечно), заточенная под язык программирования. Редактор должен оперировать конструкциями языка а не символами. Простой пример — по клавише сразу появляется заготовка оператора for со всеми скобками b точками с запятой. Редактор ДОПУСКАЕТ символьный ввод ТОЛЬКО в нужных местах. Программист просто не сможет изменить ключевое слово, стереть скобку и т.д.

Действительно хорошая идея!

LVV>Отталкиваться надо от семантики языка — почитайте и Страуструпа о том же в Дизайн и эволюция.
LVV>Соответственно редактор сразу работает с внутренним представлением программы (синтаксчески-семантичекой конструкцией программы). О, только что идея пришла в голову, что внутренним представлением может быть IL!!

Гм. А как насчёт оптимизации? Или потом "компилировать окончательно"?
А если программа находится в ещё не готовом виде и её просто нельзя откомпилироваь в MSIL?

LVV>Таким образом, при таком редакторе нужен будет только генератор кода. Парсер и лексер — в принципе не нужны! В том классическом виде, как они сейчас понимаются. Особенно лексер ( в смысле сканер). Хотя лекго может быть выполнена обратный перевод в текст (для совместимости).
LVV>Естественно, редактор должен обладать полной информацией по синтаксису и семантике языка.

Я так понимаю, в редакторе будут помечаться места, где можно что-то писать своё?
А фактически даже не писать, а в соответствии с грамматикой языка редактор может предоставлять список возможных "ходов".

---

PS. Не воспринимайте серьёзно, почему-то представилось:
Вот программист хочет написать a = b + c;
написал
a = b
и нажал Ctrl+Space.
IDE заглянул в грамматику, там написано "+" | "-" | "*" | "/"
и выдаёт wizard:

"Выбор арифметического оператора"

  Этот мастер соберёт все необходимые 
    сведения и поможет Вам выбрать
   арифметический оператор для Вашей
  программы. Для продолжения нажмите
              клавишу "Дальше"
     
      {Дальше>>} {Отмена}

на следующей закладке

"Выборите подходящий оператор"
  ( )  +
  ( )  -
  ( )  *
  ( )  /
  ( )  Всё равно
  (*)  Выбрать наилучший

{<<Назад} {Дальше>>} {Отмена}

далее

"Выбор арифметического оператора"

      Мастер выбора арифметического 
      оператора собрал все необходимые
  сведения для установки арифметического 
      оператора в Вашу программу. 
    
    Для завершения установки нажмите 
          клавишу "Готово"

{<<Назад} {Готово>>} {Отмена}

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

LVV>Компилятор в своем классическом виде — это устаревшая концепция.
LVV>ДОСТАЛО в IDE набирать программу посимвольно!
LVV>Нуж на просто другая IDE (редактор кода, конечно), заточенная под язык программирования. Редактор должен оперировать конструкциями языка а не символами. Простой пример — по клавише сразу появляется заготовка оператора for со всеми скобками b точками с запятой. Редактор ДОПУСКАЕТ символьный ввод ТОЛЬКО в нужных местах. Программист просто не сможет изменить ключевое слово, стереть скобку и т.д.

Вобщем UML

На самом деле для промышленного применения такая концепция не годится, только студентов учить.

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

LVV>Здравствуйте, VladD2, Вы писали:
LVV>Все поскипано.
LVV>Компилятор в своем классическом виде — это устаревшая концепция.
LVV>ДОСТАЛО в IDE набирать программу посимвольно!
LVV>Нуж на просто другая IDE (редактор кода, конечно), заточенная под язык программирования. ...

Симони, слышь, люди что хотят! http://www.intentionalsoftware.com/

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

LVV>Нуж на просто другая IDE (редактор кода, конечно), заточенная под язык программирования. Редактор должен оперировать конструкциями языка а не символами. Простой пример — по клавише сразу появляется заготовка оператора for со всеми скобками b точками с запятой. Редактор ДОПУСКАЕТ символьный ввод ТОЛЬКО в нужных местах. Программист просто не сможет изменить ключевое слово, стереть скобку и т.д.



Проснулся. В Gupta SQLWindows — это было еще в 94-ом году! Кое что скоро появится в Видби.

Но это все редактирование кода. Не более. Да удобчно, да быстро, но только то!

А компилятор давет возможность решения именно алгоритмических проблем.

Идея языка без текста утопична. Гуптори быстро разбили себе лоб об простое хранение версий. Нонтроль версий прекрасно работает для текста, но не для бинарного представления.

Намного проще и грамотнее сделать редактор который будет все так же загружать текст, но редактировать как ты говоришь.

Но еще раз повторю, сам язык от этого не исчезнет и его возможности шире не станут.

Я не мало работал на Гупте и мне даже нравился его редактор. Но редактор в студии объективно мощьнее, да и работать с текстом за частую гибче, чем в рамках спец-редактора.


В общем, это разные задачи. Одна другую не заменяет.

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

M>

M>"Выбор арифметического оператора"

M>  Этот мастер соберёт все необходимые 
M>    сведения и поможет Вам выбрать
M>   арифметический оператор для Вашей
M>  программы. Для продолжения нажмите
M>              клавишу "Дальше"
         
   Эта операция может знять 
        несколько митут...
     
M>      {Дальше>>} {Отмена} 
M>

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

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

M>>

M>>"Выбор арифметического оператора"

M>>  Этот мастер соберёт все необходимые 
M>>    сведения и поможет Вам выбрать
M>>   арифметический оператор для Вашей
M>>  программы. Для продолжения нажмите
M>>              клавишу "Дальше"
         
VD>   Эта операция может знять 
VD>        несколько митут...
     
M>>      {Дальше>>} {Отмена} 
M>>

Работа мастера завершена

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

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

VD>

VD>Проснулся. В Gupta SQLWindows — это было еще в 94-ом году! Кое что скоро появится в Видби.
А должно было появиться — в году этак 1984
VD>Но это все редактирование кода. Не более. Да удобчно, да быстро, но только то!
Не-е-е-е-е-т!
Эт я просто про редактор написал, а здесь же гипертекстовая организация проекта с завязкой на код здорово катит!
VD>А компилятор давет возможность решения именно алгоритмических проблем.
Только лексить и парсить — не требуется правильный текст — он правильный!
Нужна только часть касающаяся перевода — Даже промежуточное представление генерировать отдельно специально — не нужно — оно при вводе сразу генерится.
VD>Идея языка без текста утопична. Гуптори быстро разбили себе лоб об простое хранение версий. Нонтроль версий прекрасно работает для текста, но не для бинарного представления.
Ага, просто никто всерьез этим не занимался. Не вижу принципиальных проблем хранить версию текста или версию программы ( на IL — см. выше).
VD>Намного проще и грамотнее сделать редактор который будет все так же загружать текст, но редактировать как ты говоришь.
Ну, так это дополнительная фича, естественно для обратной совместимости с сегодняшними компиляторами-редакторами.
VD>Но еще раз повторю, сам язык от этого не исчезнет и его возможности шире не станут.
И не надо! Исчезнет масса рутинной работы и куча раздражающих ошибок. Особеноо для начинающих.
VD>Я не мало работал на Гупте и мне даже нравился его редактор. Но редактор в студии объективно мощьнее, да и работать с текстом за частую гибче, чем в рамках спец-редактора.
VD>В общем, это разные задачи. Одна другую не заменяет.
Да. Только лексить и парсить правильный текст не надо. А отсюда все разговоры о написании лекс ера и парсера — просто не нужны. Хотя о семантике и гамматике и внутреннем представлении — обязательно!

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

M> Действительно хорошая идея!
M>Гм. А как насчёт оптимизации? Или потом "компилировать окончательно"?
M>А если программа находится в ещё не готовом виде и её просто нельзя откомпилироваь в MSIL?
Ну, это еще в 70-х проходили — так называемые пошаговые компиляторы.
M>Я так понимаю, в редакторе будут помечаться места, где можно что-то писать своё?
M>А фактически даже не писать, а в соответствии с грамматикой языка редактор может предоставлять список возможных "ходов".
M>PS. Не воспринимайте серьёзно, почему-то представилось:
M>Вот программист хочет написать a = b + c;
M>написал
M>a = b
M>и нажал Ctrl+Space.
M>IDE заглянул в грамматику, там написано "+" | "-" | "*" | "/"
M>и выдаёт wizard:
Поскипано
Не, кроме арифметических операций представить ничего невозможно, да
Как раз выражения разрешается вводить посимвольно.
Но тут прямо просится следующее:
— следитбь за вводом чисел;
— следить за объявленными-необъявленными именами.
Это навскидку только.
M>

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

LVV>>Компилятор в своем классическом виде — это устаревшая концепция.
LVV>>ДОСТАЛО в IDE набирать программу посимвольно!
AVK>Вобщем UML
Ну, в системах проектирования — аналогичные идеи тоже катят.
AVK>На самом деле для промышленного применения такая концепция не годится, только студентов учить.
Студентов учить — это да.
Но почему в промышленном программировании не катит? Доводы?

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

AVK>>Вобщем UML
LVV>Ну, в системах проектирования — аналогичные идеи тоже катят.

Почему проектирования? UML это не только проектирование.

LVV>Но почему в промышленном программировании не катит? Доводы?

Неудобно и неприспособлено к написанию реальных систем — много лишних действий и плохо себя ведет при сложном коде.

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

LVV>>Но почему в промышленном программировании не катит? Доводы?
AVK>Неудобно и неприспособлено к написанию реальных систем — много лишних действий и плохо себя ведет при сложном коде.
Ввобще-то откуда такие выводы? Где-нить юзал подобный инструмент?
ИМХО — после проб можно и подкорректировать, что особо неудобно.

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

M>> Действительно хорошая идея!
M>>Гм. А как насчёт оптимизации? Или потом "компилировать окончательно"?
M>>А если программа находится в ещё не готовом виде и её просто нельзя откомпилироваь в MSIL?

LVV>Ну, это еще в 70-х проходили — так называемые пошаговые компиляторы.

А это точно, что с помощью пошаговой компиляции можно сохранять любые незавершённые конструкции?

M>>Я так понимаю, в редакторе будут помечаться места, где можно что-то писать своё?
M>>А фактически даже не писать, а в соответствии с грамматикой языка редактор может предоставлять список возможных "ходов".
M>>PS. Не воспринимайте серьёзно, почему-то представилось:
M>>Вот программист хочет написать a = b + c;
M>>написал
M>>a = b
M>>и нажал Ctrl+Space.
M>>IDE заглянул в грамматику, там написано "+" | "-" | "*" | "/"
M>>и выдаёт wizard:
LVV>Поскипано
LVV>Не, кроме арифметических операций представить ничего невозможно, да

Это ж я ж как бы заранее извинился, что это ж была ж как бы шутка.
Но навеяно как раз пониманием следующего:

LVV>Как раз выражения разрешается вводить посимвольно.
LVV>Но тут прямо просится следующее:
LVV> — следитбь за вводом чисел;
LVV>- следить за объявленными-необъявленными именами.
LVV>Это навскидку только.

Совершенно согласен.

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

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

LVV>Ввобще-то откуда такие выводы?

Я видел много способов описания кода, но ничего удобнее текста пока не приметил.

LVV>Не, кроме арифметических операций представить ничего невозможно, да
LVV>Как раз выражения разрешается вводить посимвольно.
LVV>Но тут прямо просится следующее:
LVV> — следитбь за вводом чисел;
LVV>- следить за объявленными-необъявленными именами.
LVV>Это навскидку только.

Имеет смысл делать что-то вроде Smart-Tags, более жёсткая автоматизация бесперспективна. По мере ввода текста анализатор колбасит и навешивает ярлычки на наиболее подозрительные места. FxCop+фоновая компиляция в одном флаконе.

Да ещё в модели SmartTags придётся умерить настырность, а то все знают, как Word автокорректирует А программеры — это же не юзеры. Им такая "помощь" ещё больше обидит. А уж за жёсткий контроль так просто сотрут с винта систему, даже feedback не пошлют.

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

VD>>Проснулся. В Gupta SQLWindows — это было еще в 94-ом году! Кое что скоро появится в Видби.
LVV>А должно было появиться — в году этак 1984

Боюсь тебя огорчить, но уже в 95-от в Гупту был добавлен экспорт/импорт из текстового формата. Так что на сегодня кроме как чудным редактором они не отличаются. Что же касается 84-го... Идея тупиковая, так что хоть 2024-ом, хоть в 1824, значения не имеет.

LVV>Не-е-е-е-е-т!

Агащасблин.

LVV>Эт я просто про редактор написал, а здесь же гипертекстовая организация проекта с завязкой на код здорово катит!

Еще одно красивое (в прошлом) слово. Жаль только еще более бессмысленное. Гипертекст и разработка ПО вещи очень далекие.

LVV>Только лексить и парсить — не требуется правильный текст — он правильный!

Это мелкая подзадача. Ее решение давно найдено и мало кого интересует. А вот отсуствие читабельной "твердой копии" — это огромнейшая проблема.

LVV>Нужна только часть касающаяся перевода — Даже промежуточное представление генерировать отдельно специально — не нужно — оно при вводе сразу генерится.

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

LVV>Ага, просто никто всерьез этим не занимался.

Ты серьезно считаешь себя умнее, чем весь остальной мир? Все кто занимались подобным подходом, продумывали разные варианты. Догадайся на чем остановились?

LVV> Не вижу принципиальных проблем хранить версию текста

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

LVV> или версию программы ( на IL — см. выше).

IL не позволяет хранить всю информацию присутствующую в коде. Да и работать с ним неудобно (практически невозможно).

LVV>Ну, так это дополнительная фича, естественно для обратной совместимости с сегодняшними компиляторами-редакторами.

Не. Это единственный разумный вариант. Но тут мы приходим к одному выводу. Компилятор все равно нужен. А стало быть все это бессмысленные рассуждения, так как текстовый редактор не более чем тулз для редактирования кода.

LVV>И не надо!

Зачем тогда вообще было эту подветку открывать? Тут идет речь о создании нового языка. Зачем переводить все в бессмысленные рассуждения на сопутствующие темы?

LVV> Исчезнет масса рутинной работы и куча раздражающих ошибок. Особеноо для начинающих.

Ни грамма не исчезнет. То о чем ты говоришь, если откинуть утопичные идеи — это всего лишь интеллектуальный редактор кода. Редактор в студии и так очень интеллектуальный. И не факт, что повышение ограничений понравится людям. А главное, что это офтопик в данной теме.

LVV>Да. Только лексить и парсить правильный текст не надо.

Это не та проблема, над решением которой стоит трудиться. Интеллектуальный редактор не замена компилятору.

LVV> А отсюда все разговоры о написании лекс ера и парсера — просто не нужны.

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

PS

Подитожу...

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

Отсюда разговоры о ненужности парсера и лексера бессмысленны. Разговаривать имеет смысл только об интеллектуальном редакторе. Но это уже выходит за пределы этой темы.

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

M>А это точно, что с помощью пошаговой компиляции можно сохранять любые незавершённые конструкции?

Качество будет хреновое и ограничений куча. Но в принципе можно. В гупте так и было.

Вот только задалбывать будет, что нельзя не объявив ххх его использовать в выражении. Делать все по порядку иногда очнь задалбывает.

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

M>Имеет смысл делать что-то вроде Smart-Tags, более жёсткая автоматизация бесперспективна. По мере ввода текста анализатор колбасит и навешивает ярлычки на наиболее подозрительные места. FxCop+фоновая компиляция в одном флаконе.

О, блин! Васик.Видби, адназначна . Мелкие файлы и то тормозят как бревно в дверном проеме. А в итоге нифрена не может угадать, что я пытаюсь изобразить. Я с описанием импорта функции из длл бьюсь, а он урод предлагает слово статик на dim махнуть. Тупой. Не значет, что я его с шаредом перепутал.

В общем, это называется американской помешью. Уж лучше по проще (как в Шарпе), но не так тормозно и "интеллектуально".

M>Да ещё в модели SmartTags придётся умерить настырность, а то все знают, как Word автокорректирует

Во-во. Ворд еще ладно. А вот то, что в ХаРэ-шном Ёкселе эти уродские теги закрыть было нельзя — это уже задница. Перекрывают данные и все тебе.

M>А программеры — это же не юзеры. Им такая "помощь" ещё больше обидит. А уж за жёсткий контроль так просто сотрут с винта систему, даже feedback не пошлют.

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

LVV>Но почему в промышленном программировании не катит? Доводы?

Потому-что неудобно. Навороченная среда вроде студии дает все те же приемущества, только не засовывает в уродские рамки создаваемые подобными "безспарсерными" идеологиями.

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

LVV>Ввобще-то откуда такие выводы? Где-нить юзал подобный инструмент?

Подтверждаю. Я юзал. Неудобно. В студии на порядок лучше.

LVV>ИМХО — после проб можно и подкорректировать, что особо неудобно.

Вот народ и пришел к выводу, чно нужно наворачивать обычный редактор, а не пытаться обойтись без парсера.

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


VD>Качество будет хреновое и ограничений куча. Но в принципе можно. В гупте так и было.
VD>Вот только задалбывать будет, что нельзя не объявив ххх его использовать в выражении. Делать все по порядку иногда очнь задалбывает.
Не обязательно. Вспомните ассемблер. Там имя можно использовать ДО объявления — и ничего. Претензии по по поводу двухпроходной трансляции — не принимаются — хорошо известен принцип однопроходной трансляции с возвратами для корректировки ранее отмеченного места по результатам вновь полученной информации. Просто окончательная трансляция с оптимизацией не делается, пока все не объявлено. А так — пусть себе висит флажок, что не объявлено.

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

VD>Боюсь тебя огорчить, но уже в 95-от в Гупту был добавлен экспорт/импорт из текстового формата.
Ну, это очевидно, что надо было делать так с самого начала — для обратной совместимости.
LVV>>Эт я просто про редактор написал, а здесь же гипертекстовая организация проекта с завязкой на код здорово катит!
VD>Еще одно красивое (в прошлом) слово. Жаль только еще более бессмысленное. Гипертекст и разработка ПО вещи очень далекие.
Ага, а перекрестные ссылки по определениям и вызовам в модулях-классах? Что это как не гипертекст.
VD>Это мелкая подзадача. Ее решение давно найдено и мало кого интересует. А вот отсуствие читабельной "твердой копии" — это огромнейшая проблема.
БЛИНННННН!!!!!!!!! да кто говорит про отсутствие-то!!!!!!! Имейте себе на здоровье! Одно другому — не мешает.
VD>Ничего ни где сразу не возникает. В таком редакторе ты получишь частично разобранный, в дерево разбора, код. Не более того. Никакого промежуточного представления ты не получишь. Ты даже нормального дага не получишь.
VD>Ты серьезно считаешь себя умнее, чем весь остальной мир? Все кто занимались подобным подходом, продумывали разные варианты. Догадайся на чем остановились?
"Это спорный вопрос, между прочим. Ничего плохого я вам не сделал" (с) Лукашин.
А текстовый редактор — потому что проще реализовать, быстрей выпумстить в производство и соответственно, получить больше прибыли. Или это не понятно?
Страуструп именно о такой интегрированной среде говорит (Дизайн и эволюция С++ — завтра принесу книжку на работу и с точностью до предложения все напишу). ИДЕ ДОЛЖНА строится вокруг СЕМАНТИКИ языка. Я с ни абсолютно согласен — это к вопросу о том, кто умнее
LVV>> Не вижу принципиальных проблем хранить версию текста
VD>Так и стали делать. Только при этом говорить, об отсутствии чего бы то ни было просто смешано. Получается стандартнейшая схема плюс интеллектуальный редактор.
Ну так ......!!!!
И парсить нужды — нету!
VD>Не. Это единственный разумный вариант. Но тут мы приходим к одному выводу. Компилятор все равно нужен. А стало быть все это бессмысленные рассуждения, так как текстовый редактор не более чем тулз для редактирования кода.
Не-а! Это — основа ИДЕ — читайте Страуструпа (не меня — я скромный )

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

VD>Отсюда разговоры о ненужности парсера и лексера бессмысленны. Разговаривать имеет смысл только об интеллектуальном редакторе. Но это уже выходит за пределы этой темы.
Ну, я понял, что тебе эта тема просто неинтересна.
И естественно, новый язык ты собираешься реализовывать стандартнейшим способом.
Жаль.

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

LVV>А текстовый редактор — потому что проще реализовать, быстрей выпумстить в производство и соответственно, получить больше прибыли. Или это не понятно?

Поэтому наверное в линуксе самые навороченные радакторы кода

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

LVV>Не обязательно. Вспомните ассемблер. Там имя можно использовать ДО объявления — и ничего. Претензии по по поводу двухпроходной трансляции — не принимаются — хорошо известен принцип однопроходной трансляции с возвратами для корректировки ранее отмеченного места по результатам вновь полученной информации. Просто окончательная трансляция с оптимизацией не делается, пока все не объявлено. А так — пусть себе висит флажок, что не объявлено.

У тебя в редакторе будет безпроходная трансляция. И возвратов быть не может. Или контроля не будет, а это всю твою идею сводит на нет.

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

VD>>Боюсь тебя огорчить, но уже в 95-от в Гупту был добавлен экспорт/импорт из текстового формата.
LVV>Ну, это очевидно, что надо было делать так с самого начала — для обратной совместимости.

Тогда зачем обсуждать создание редактора взамен парсера, если без парсера все равно никуда не денешся?

Посмотри на наши идеи по поводу метапрограммирования Метапрограммирование (к топику о новом языке)

Автор: AndrewVK
Дата: 16.12.03

. Там строится дерево которое можно будет изменять программно. Твой редактор может воспользоваться этим механизмом как движком позволяющим динамически добавлять код прямо в дерево разбора.

Но заводить разговор о замене редактором парсера бессмысленно.

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


LVV>БЛИНННННН!!!!!!!!! да кто говорит про отсутствие-то!!!!!!! Имейте себе на здоровье! Одно другому — не мешает.

Ты Re: А это — мое видение.

Автор: LaptevVV
Дата: 11.12.03

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

LVV>>Ну, это очевидно, что надо было делать так с самого начала — для обратной совместимости.

VD>Тогда зачем обсуждать создание редактора взамен парсера, если без парсера все равно никуда не денешся?
Не взамен — а токмо для разбора текстов, подготовленных в других местах.
VD>Посмотри на наши идеи по поводу метапрограммирования Метапрограммирование (к топику о новом языке)

Автор: AndrewVK
Дата: 16.12.03

. Там строится дерево которое можно будет изменять программно. Твой редактор может воспользоваться этим механизмом как движком позволяющим динамически добавлять код прямо в дерево разбора.
Вот!!! Это именно то, о чем я говорил с самого начала — ты это классно сформулировал!
Дерево — только не разбора, а синтаксически-семантическое делается сразу — в редакторе.
А уж из него можно генерить — хочешь тебе — текст, хочешь — IL.
VD>Но заводить разговор о замене редактором парсера бессмысленно.
А парсер — это фактически конвертер из текста в дерево. Это дополнительная составляющая интегрированной среды (заметь, я не говорю — компилятора).

> Редактор ДОПУСКАЕТ символьный ввод ТОЛЬКО в нужных местах. Программист просто не сможет изменить ключевое слово, стереть скобку и т.д.

Это неправильно. Резко уменьшаются возможности редактирования.

Часто из одного корректного текста можно перейти к другому корректному тексту только через некорректный.

Пример:

int a; 
...
a = 1;

Перед нами стоит задача поменять тип переменной a на строковый.
У нас это не получится, потому что тип a мы не сможем поменять, потому что есть присваивание числа, а поменять a = 1 на строку тоже не сможем, потому что a объявлена как int.

Именно, поэтому системы, которые поддерживают только корректный ввод данных — обречены.

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

LVV>Не взамен — а токмо для разбора текстов, подготовленных в других местах.

Тут оно как с беременностью. Или парсер нужен. Или нет. А если он нужен. То редактор всего лишь удобная фишка.

Еще раз повторю. Если у тебя есть подобная идея, то создай отдельный топк. Не в последню очередь из-за этой подветки темы переехали сюда из дотнета.

Если бы модератором был я. То эта подветка уеха лы бы из той темы сразу же как я ее заметил бы.

LVV>Дерево — только не разбора, а синтаксически-семантическое делается сразу — в редакторе.

Это называется AST (абстрактное синтаксическое дерево). Более того унас это даже будет смесь AST и рефлекшона. Так вот создание AST в обход парсера являлось офтопиком в той теме. Неужели это не ясно?

LVV>А уж из него можно генерить — хочешь тебе — текст, хочешь — IL.

Ну, и зачем тогда говорить о редакторе как об отдельной фиче? Будет готов парсер. Возьми из него описание AST и сделай редактор который будет создавать AST. Вот только в AST много информации уже потеряно. Тут нужно несколько расширять AST вводя в него дополнительные элементы вроде коментариев и строковых представлений литералов (представь ты введешь 1.12345456, а тебе его перепишут c экспонентой.

LVV>А парсер — это фактически конвертер из текста в дерево.

Парсер это более сложная сущоность. Без него говорить о редакторе бессмысленно. Кроме синтаксического разбора в нем делаются семантический разбор и оптимизации. Твое редактор должен хавать уже готовое дерево. Причем дерево нужно сохранять обратно в текст. Самопальные форматы провалились по полной программе.

LVV> Это дополнительная составляющая интегрированной среды (заметь, я не говорю — компилятора).

Это тупиковый подход. Реалистический был бы использование полноценного парсера для загрузки и сериализации в код. Нечто типа полноценного код-дом-провайдера (если ты слышал о таком). Тогда на долю редактора остается уже вполне посильная задача — изменение расширенного AST.

ЗЫ

Еще раз повторю. Не стоило переключать чужую тему. Для обсуждения этой идеи нужно было создать отдельную ветку.

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

>> Редактор ДОПУСКАЕТ символьный ввод ТОЛЬКО в нужных местах. Программист просто не сможет изменить ключевое слово, стереть скобку и т.д.

DG>Это неправильно. Резко уменьшаются возможности редактирования.

DG>Часто из одного корректного текста можно перейти к другому корректному тексту только через некорректный.

DG>Пример:
DG>

DG>int a; 
DG>...
DG>a = 1;
DG>

DG>Перед нами стоит задача поменять тип переменной a на строковый.
DG>У нас это не получится, потому что тип a мы не сможем поменять, потому что есть присваивание числа, а поменять a = 1 на строку тоже не сможем, потому что a объявлена как int.
DG>Именно, поэтому системы, которые поддерживают только корректный ввод данных — обречены.

Поменять тип можно — только не ручками, а выбрав из списка. На втором операторе тут же флаг повиснет: несоответствие типов.
Это одна из простых технических проблем, которых, очевидно, в процессе реализации всплывет множество. Каждый раз надо будет вырабатывать некоторое решение. Но только при реальной эксплуатации можно будет сказать, что удобно, а что — нет.

Я году в 93-м видел такой редактор, сделанный студентами.
Он кажется позволял редактировать программы на Паскале.
Впрочем ему было все равно, потому что грамматика языка хранилась
отдельно и теоретически его можно было настроить на любой язык.

На практике пользоваться таким редактором было жутко неудобно.
Как тут уже подметили, пользоваться им можно только для обучения,
причем только на начальных этапах.
Потом он не помогает, а жутко мешает.

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

В общем для исследований эта тема может быть интересной,
но для жизни плюсов я лично почти не вижу. А вот минусов — полно.

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


VD>Еще раз повторю. Не стоило переключать чужую тему. Для обсуждения этой идеи нужно было создать отдельную ветку.
Влад, я ж не специально! И в мыслях не было переключать! Просто компиляторы — это мне интересно, я еще по Грису с этим разбирался. Но постепенно сложилось ИМХО, что особенно для начинающих программеров предложенная IDE куда как лучше подойдет. Вот и прописал.
Претензии вообще-то к модератору — надо было сразу отцепить — как сейчас это и сделали.
Все, данный вопрос закрываем, хорошо?

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

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

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

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

LVV>Поменять тип можно — только не ручками, а выбрав из списка. На втором операторе тут же флаг повиснет: несоответствие типов.
LVV>Это одна из простых технических проблем, которых, очевидно, в процессе реализации всплывет множество. Каждый раз надо будет вырабатывать некоторое решение. Но только при реальной эксплуатации можно будет сказать, что удобно, а что — нет.


Сделав текстовую нотацию для UML 2.0, мы, по реакции customer-ов, поняли, что это были именно то, что им нужно. При наличии возможности выбирать тип из списка или заменять его прямо в тексте, юзеры предпочитают второе.
Правда у нас идет постоянная проверка вводимого кода, так что набрав, скажем, "b+1" где b — переменная булевского типа, юзер незамедлительно получит сообщение, что нет оператора + с сигнатурой (Boolean,Integer) и сам оператор + будет подчеркнут.

Лучше всего, когда тул предоставляет оба подхода.

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

LVV>Здравствуйте, VladD2, Вы писали:
LVV>Все поскипано.
LVV>Компилятор в своем классическом виде — это устаревшая концепция.
LVV>ДОСТАЛО в IDE набирать программу посимвольно!
LVV>.......... Простой пример — по клавише сразу появляется заготовка оператора for со всеми скобками b точками с запятой. ........

Это есть уже реализровано в Eclipse for Java, IntelliJ IDEA, Visual Assist, Code Smart 2003, CodeObjectSetup. Действительно хорошая и удобная штука.
А остальное к сожадению ненужно, ограничивая свободу пользователя мы только усложняем ему жизнь, если вы придумаєте интерфейс пользователя удобный чтобы всё так же быстро как и при клавиатурном наборе, а работая мышкой это медленно долго и неэфективно, к тому же ещё недостаточно гибко, я пользовался немного программой у которой есть внутренний скриптовый язык таким образом сделанный как будто неплохо но неудобно.

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

LVV>>Не, кроме арифметических операций представить ничего невозможно, да
LVV>>Как раз выражения разрешается вводить посимвольно.
LVV>>Но тут прямо просится следующее:
LVV>> — следитбь за вводом чисел;
LVV>>- следить за объявленными-необъявленными именами.
LVV>>Это навскидку только.

M>Имеет смысл делать что-то вроде Smart-Tags, более жёсткая автоматизация бесперспективна. По мере ввода текста анализатор колбасит и навешивает ярлычки на наиболее подозрительные места. FxCop+фоновая компиляция в одном флаконе.

M>Да ещё в модели SmartTags придётся умерить настырность, а то все знают, как Word автокорректирует А программеры — это же не юзеры. Им такая "помощь" ещё больше обидит. А уж за жёсткий контроль так просто сотрут с винта систему, даже feedback не пошлют.

Visual Assist + Madinina CodeObject, а ещё такого много в IDE для Java, типа Eclipse и IDEA, там ети фишки просто очень класно реализированы и не нужен отдельный редактор, а просто плагин к студии, я ввёл новый идентификатор, оно мне сразу предлагает создать переменную или метод, начал вводить public оно стразу предлагает шаблон обявления метода, вот чего мне не хватает в студии, а ещё рефакторинга такого же харошего как и в IntelliJ IDEA, хотя говорят в витби должено появится, сейчас использую C# Refactory, но по субъективным впечатлениям он слабоват.

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

LVV>Да, этим сейчас занимаются. Есть даже сайт в России.
А можно пожалуйста ссылки? Меня это очень заинтересовало.

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

LVV>[...]
Дык Excel же!
Только с отрезанным VBA

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

LVV>Мои студенты пытались даже обобщить это дело на класс процедурных языков.
Мнээ... ммм... а студенты не против, если их наработки нам показать? Я бы с огромным интересом глянул, хотя бы на экзешник, сорцы б вообще идеально...

И вообще, есть доступные ресурсы по этому делу? А то я поиском много нашел (в основном статьи на ACM), но там НАСТОЛЬКО все высоконаучно, что я ни фига не понял

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

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

LVV>>Да, этим сейчас занимаются. Есть даже сайт в России.
КО>А можно пожалуйста ссылки? Меня это очень заинтересовало.
Сходите сюда
Они даже издают журнал. Эти ребята имеют ОЧЕНЬ МНОГО ссылок на дела, связанные с Адаптивными Обучающими системами.
Из наших ключевая фамилия — Брусиловский. Он очень много по адаптивным системам написал. И этом сайте можно найти переводы его статей.

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

Я тоже когда-то думал над подобной идеей, но забросил ввиду явной недостачи ресурсов да и Sun к тому времени уже что-то наваял подобное. А вообще, когда какой-то глобоко уважаемый дядя на предложение о какой-то даже "немножко революционной идее" говрит, что это всё туфта — то мне вспоминаются слова(приблизительно) какого-то не менее уважаемого в прошлом дяди: "Я объездил эту страну вдоль и впоперек, был в самых известных униврситетах и центрах, разговаривал с самыми уважаемыми и видными учёнами страны и могу вас заверить, что обработка информации — это причуда, которая не продлится и полгода" После этого подобные идеи я со "спецами" не убсуждаю разве что смежные задачи

Здравствуйте, King of a Stellar War, Вы писали:

KOA>Я тоже когда-то думал над подобной идеей, но забросил ввиду явной недостачи ресурсов да и Sun к тому времени уже что-то наваял подобное. А вообще, когда какой-то глобоко уважаемый дядя на предложение о какой-то даже "немножко революционной идее" говрит, что это всё туфта — то мне вспоминаются слова(приблизительно) какого-то не менее уважаемого в прошлом дяди: "Я объездил эту страну вдоль и впоперек, был в самых известных униврситетах и центрах, разговаривал с самыми уважаемыми и видными учёнами страны и могу вас заверить, что обработка информации — это причуда, которая не продлится и полгода" После этого подобные идеи я со "спецами" не убсуждаю разве что смежные задачи

Грамотный специалист тебе в ответ на любую безумную идею буквально в полчаса объяснит, что во-первых это невозможно реализовать, во-вторых в этом нет никакой потребности, и в третьих все это уже давным-давно реализовано.

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


LVV>...Естественно, редактор должен обладать полной информацией по синтаксису и семантике языка.
LVV>Вокруг такого редактора и отладчик легче строить и профайлер.
LVV>Мои студенты пытались даже обобщить это дело на класс процедурных языков.

Лет 10 назад видел такой IDE с компилятором для Modula-2.
Очень неудобно было работать.

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

LVV>ДОСТАЛО в IDE набирать программу посимвольно!
LVV>Нуж на просто другая IDE (редактор кода, конечно), заточенная под язык программирования.
Во, вспомнил! Кажется, Action Script в Macromedia Flash подобным образом устроен.

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

M>Я так понимаю, в редакторе будут помечаться места, где можно что-то писать своё?
M>А фактически даже не писать, а в соответствии с грамматикой языка редактор может предоставлять список возможных "ходов".

Представил тулбокс в студии, в котором лежат компоненты "for()", "int", "+" и т.п.

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

S>Грамотный специалист тебе в ответ на любую безумную идею буквально в полчаса объяснит, что во-первых это невозможно реализовать, во-вторых в этом нет никакой потребности, и в третьих все это уже давным-давно реализовано.

Так это замечательно! Для этого и нужны грамотные специалисты.
Но после критических комментариев можно продолжать работу с удвоенной силой.
И искать варианта улучшения проблемных мест и подходов.

Недостаток профессионализма в зашорености мышления
И от этого не избавиться не кому.
Надо использовать опыт и знания более компетентных коллег в своих целях, при реализации своих идей.
Но операться на "жесткость ума" не стоит.

А есть еще такая замечательная вещь, как ReSharper. Вроде как и текстовой редактор без ограничений, а вроде как и реализация всех подобных мечтаний. Наливай да пей.

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

Небезизвестный Lutz Roeder тоже думал на эту тему.

http://aisto.com/roeder/paper/


Interactive Source Code — http://aisto.com/roeder/paper/InteractiveSourceCode.ppt
Extensibility and Visualiztion of Source Code Documents — http://aisto.com/roeder/paper/SourceCodeDocuments.ppt

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

[..]

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