OberonCore

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

В моем понимании они должны быть объектами стандартной библиотеки. Стало быть, они должны храниться во встроенной базе данных. И это не только растровые картинки, но и объекты с изменяемой геометрией: окна, панели, полосы прокрутки и т.п. элементы интерфейса. Их уже нельзя назвать данными в чистом виде, поскольку они содержат и код, описывающий поведение.

База данных - это вообще-то двоичный файл...
А то, что дерево можно хранить как угодно - это понятно...

Вообще-то для первоначального обучения программированию обучения это все совершенно неважно. А важно ставить студиоза в жесткие рамки, когда он НЕ СМОЖЕТ писать КАК УГОДНО, а только так, как предписано. Принудительные пробелы - это пример из это сферы. А Сергей хочет в результате действительно получить интегрированную среду, в которой с минимальными усилиями можно создавать приложения достаточной для его задач мощности.
Собственно, я об этом думал еще в 1992 году - примерно в то же время, когда Страуструп писал свою книжку Дизайн и эволюция С++. Там он высказал некоторые мысли о том, какой должна быть интегрированная среда. Наши мысли в общем-то совпали.
А сейчас я переориентировался на обучение, так как меня уже достало одно и тоже долдонить для каждого нового первокурсника. Нужно их просто ставить в позу и вырабатываьб условный рефлекс.
Модель - нужна для оценивания, иначе можно было бы попробовать решить все это в рамках существующих сред.

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

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

Ссылка http://www.jetbrains.com/mps уже есть на первой странице, вот добавка к ней для комплекта: http://habrahabr.ru/blogs/development/66094/

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

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

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

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

То, как сейчас ведется обучение программированию в вузах, меня вообще повергает в ужас. Вижу только один положительный пример - курсы "Специалист" при МГТУ им. Баумана. Надеюсь, что это не сочтут за рекламу (сайт не самый посещаемый). Этот опыт надо просто брать и перенимать. Правда, начальное обучение там ведется на Турбопаскале, который уже порядком устарел, - Блэкбокс был бы более уместен.

Мои впечатления от обучения в одном из лучших вузов:

• Студенты адаптируют к своим заданиям программы, написанные когда-то старшекурсниками (кому в этом везет больше, кому - меньше)
• Студенты пишут программы друг за друга, а некоторые даже нанимают программистов за деньги
• Преподаватели занижают оценки за отличные оригинальные программы, если те не повторяют слово в слово то, что было разобрано на семинаре - под предлогом того, что программы якобы списаны из интернета
• Сдача лабораторных передшествует разбору соответствующих тем на семинарах
• В лекциях говорится буквально полслова о серьезных вещах (в интернете с трудом докапываешься за день - по-английски), которые и на семинарах не разбираются, но делать по ним лабораторки приходится
• Задания лабораторок искусственно усложняются - писать программу нужно не естественным образом, а совершенно извращенным образом
• Каждый студент хорошо изучает только те темы, которые ему случайно попались в индивидуальном задании по лабораторным работам
• У кого-то из студентов хороший стиль программ (получили совет), у кого-то - ужасный (вообще без отступов, пробелов, по несколько операторов на строке) - преподавателям всё равно
• Проконсультироваться студентам реально не у кого
• Список рекомнедованной литературы ужасен - по таким учебникам учиться невозможно
• То программное обеспечение, которое стоит в аудиториях (уникальное старье) и дома, несовместимо друг с другом, и студентам приходится быть виртуозами-сисадминами
• Даже самых лучших студентов спасает от отчисления только взаимопомощь

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

(выделение bold моё)
Да, Вы не программист
То что Вы перечислили на жаргоне программистов называется "контролами", а по-русски "элементами управления". Я не припомню сейчас упоминание у Вас о целевой платформе, но если это Windows, то все эти контролы являются специальными окнами, и классы этих окон уже "прописаны" в WinAPI (а не во встроенной в семантический редактор базе данных!). Другое дело, если они Вас не устраивают, и Вы решили создать свой графический интерфейс.

Спасибо! Еще один красивый пример отказа от текстового представления исходного кода. Правда, до семантического редактора не дотягивает, так как ввод программного кода осуществляется с клавиатуры как текст.

Внутренний формат хранения кода XML стал уже вроде как типовым в такого рода проектах (упомяну еще Zonnon .NET). Но всё-таки встроенная СУБД более "естественна" для семантический редактор, устраняя такое лишнее звено, как парсер XML, и давая многие существенные удобства.

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

Неважно, это WinAPI или что угодно. Подход должен быть универсальным. Все объекты стандартной библиотеки должны храниться во встроенной СУБД семантического редактора, снабженные контекстной справкой, средствами поиска, пиктограммами для отображения на панели коллекций и прочими удобствами. Семантический редактор должен избавить программиста от необходимости изучать тонкости стандартных низкоуровневых технологий по документации разных компаний, представляя их в препарированном виде. Целевых платформ должно быть несколько, но, конечно, Windows - первоочередная. Кстати, там есть и другие варианты, кроме WinAPI, - есть .NET, например. Есть и кроссплатформенные.

В Википедии "контролы" называются элементами интерфейса, а не элементами управления. И это правильно. Меня, как специалиста по управлению, коробит от термина "элемент управления".

Я не думаю, что создание собственных контролов на первых порах - хорошая идея. Контролы Блэкбокса, которые выглядят слишком экзотически, в этом убеждают. Гораздо заманчивее предоставить программисту бесшовный доступ к уже имеющимся различным вариантам, включая разнообразные современные виджеты с обратной связью.

Чем-то напоминает дельфийский Code Insight. Когда работал в Delphi, всегда радовался этой технологии.

То, что в венду встроено, в WinAPI, это полнейший ужос времен Win3.x/9x. Любая мало мальски сложная программа использует собственные (ручками рисованные) контролы, да, они часто рисуются на окнах виндовозных (имеют свой HWND), и да, часто сам прикладной программист их не пишет а берет из той граф. либы которую он использует. Например VCL. Но в VCL всё плохо. Там половина контролов по сути оболочка вокруг виндовозных "стандартных" контролов, а половина свои, рисуемые на простейших виндовозных окошках. Иногда эта абстракция протекает, это различие вылазит и становится плохо.

Если взять скажем Qt, то там все контролы рисуются целиком самостоятельно. Т.е. Qt шная кнопка с т.з. винды это ни разу не кнопка.

Если взять Swing, то там ещё забавней -- там вообще используется ровно одно тяжеловесное (т.е. виндовозное) окно. А всякие кнопки, прокрутки, дочерние окна это в терминах ОС не окна. Их просто с т.з. системы НЕТ.

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

Вывод -- реализовывать свои контролы рано или поздно но придется, поэтому лучше сразу всё делать на них. С оглядкой на то, чтобы они выглядели и работали в текущем стиле текущей ОС.

Дык, так и делаем!

Именно!

Не... Лабы меняются... И технология их сдачи - тоже.

Нанимать - это не по нашей кафедре. Но писать за других - это было запросто. Сейчас у первачков такое в принципе не пройдет. Ибо 18 лабов. За неделю до пары дается весь материал на дом. Материал качественный, там все расписано по теме, примеры приведены, и 20 вариантов. Дело студиоза дома попробовать сделать пару-тройку вариантов. Потом на следующей неделе на паре все получают случайный вариант из этой лабы и должны за пару сделать. Сделал - засчитывается. Не сделал - потом будешь отдельно сдавать в таком же режиме. Практика показывает, что студиоз, дома поломавший голову, позадававший преподу вопросы, с любым вариантом вполне справляется за пару.

Вот это уж полная ерунда. См. выше технологию сдачи лаб. Курсовые - такое бывает, списывают (заочники этим страдают частенько). Ну так у нас же публичная защита курсовых: должен быть доклад по ролику-презентации, потом показ готовой работающей проги, потом ответы на вопросы. Причем, принимаем всегда вдвоем и за компьютером. Тут видать, содрал человек или сам писал. А если содрал, то разобрался или нет...

Не - см. выше.

Не, лекции все - с презентациями. Книжки все - самые серьезные.

Не, все типовое - "то, что должен знать каждый"

Было такое с нынешним 5 курсом, когда им простили по паре лаб. С тех пор - зареклись. Сделать и сдать надо - все!
А лабов - в первом семестре 18, во втором - еще 17. Так что "кто не выучил - я не виноват!"...

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

Дофига! Каждую неделю помимо лабов - консультация, на которой студиоз может решить все свои вопросы.

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

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

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

Чем и занимаемся...

Ну, занимаемся вдвоем - это сильно сказано. Обсуждаем, да. Вот зимой достаточно подробно обсуждали интерфейс. Полезно было. Сейчас - тоже полезное обсуждение. Во всяком случае, для меня. А моделью мы занимаемся. К сожалению, не кадждый день удается посвятить этому достаточно времени - много рутины... Занятия, статьи для диссера, всякие сборища типа заседания кафедры или совета института. Экспертом часто приглашают, в какие-нить члены записывают... И студент, который сейчас на 3-м курсе, но хочет эту тему развивать до диплома, тоже загружен по самое-самое... Но движемся потихоньку...

Что касается контролов собственно для семантического редактора, то им никакая особая переносимость и не требуется, как и самому редактору. Если сам редактор будет работать под .NET с его контролами (http://ru.wikipedia.org/wiki/Windows_Pr ... Foundation а также http://msdn.microsoft.com/ru-ru/library/ms752324.aspx), то этого, наверное и достаточно. Семантический редактор - это инструмент программиста-профессионала, а профессионал будет вынужден согласиться на любую более-менее доступную платформу. Он не избалованный потребитель.

Разумеется, в .NET отсутствуют специфические для семантического редактора элементы интерфейса - их придется делать самим.

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