freepascal.ru

Плюсы скрипта будут если проект не OpenSource

OpenSource он такой разный - есть лицензии запрещающие изменять код и делать форки

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

есть очень много мелких нюансов

• у меня лазарь не собирается корректно... сама компиляция проходит, но при работе начинает валиться с ошибками... мне проще скачать бинарник и не париться
• а если программист вообще не имеет установленного лазаря, а пишет на питоне, пхп или еще чем-то? ему компилировать тоже не особо интересно, ему больше нужен просто бинарник
• и т.п.

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

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

По поводу пункта

подсветка синтаксиса

предполагается использование SynEdit?
Если да, то хотелось бы, чтобы применяли гибкий настраиваемый подствечик synunihighlighter... Потому что
1) в комплекте с компонентом уже имеются 62 подстветчика (в той комплектации, что есть у меня. Если потребуется, обращайтесь, распространяю свободно...)
2) можно добавлять подсветку новых языков, дополнять с помощью специальных файлов описаний синтаксиса, без перекомпиляции...
Для создания новых и редактирования доступных языков в комплекте уже есть готовый дизайнер)

предполагается использование SynEdit?

да

обращайтесь

написал в лс

eastorwest писал(а):Если да, то хотелось бы, чтобы применяли гибкий настраиваемый подствечик synunihighlighter... Потому что

Вопрос про SynUniHighlighter (SynUniSyn). Не подскажите, где берут последние варианты исходников и компонентов, кто ведет сейчас этот проект (ссылка на сайт или контакты разработчиков), и вообще в каком состоянии сейчас проект?
Возможно, что мне потребуется для некоторых проектов нечто подобное. В одном случае для своего специализированного (под прикладные задачи) скриптового языка, а в другом случае осваиваю Open CL на паскале (пишу на Delphi, но это не принципиально).

ev писал(а):потихоньку пишу мини IDE

Хочется взглянуть ... потихоньку так, одним глазком Можно даже в качестве бета-тестера.

Хочется взглянуть

отписал в лс

Добавлено ...

Вопрос про SynUniHighlighter (SynUniSyn). Не подскажите, где берут последние варианты исходников и компонентов, кто ведет сейчас этот проект (ссылка на сайт или контакты разработчиков), и вообще в каком состоянии сейчас проект?

ситуация примерно такая (если ошибаюсь - поправьте)

• с сайта проекта скачать компонент сложно (сайт забросили или еще что - х.з.), есть отдельный линк (на версию от 2003 года)
• в Lazarus присутствует UniHighlighter (версии 2003 года), но он признан недоделанным (самим автором порта) и в малой комплектации
• есть версия (предлагаемая чуть выше) с небольшими правками, примерами и конфигами подсветки
• есть более новая версия (2005-2006 год), но пока нет данных где ее можно скачать

если есть желающие развивать компонент подсветки - пишите

v-t-l писал(а):Оформить бы его в виде гуишной замены FP IDE, с теми же меню, диалогами, хоткеями, встроенным терминалом и цветами . Чтобы школьники не приставали.

Руки прочь от линуксового консольного ИДЕ!

А в чем уникальность данного IDE? Действительно ведь есть уже продвинутые текстовые редакторы.

Есть идея сделать IDE вокруг синтаксического дерева. Т.е. по тексту генерировать (фактически компилировать) в это самое дерево и его уже отображать и вообще работать с ним. Блоки, которые откомпилировать не удалось, считать просто текстовыми блоками.
Это позволит довольно легко предлагать всякие подсказки, code insight, error insight, documentation insight и т.п. Как в современных IDE типа IDEA. И даже лучше.
Преобразовывать (т.е. редактировать) такое представление программы тоже проще, чем просто текст.
Дерево ведь в общем-то не зависит от языка. Парсеры могут быть для разных входных языков. От XML до Паскаля и Явы.
Если стандартизировать узлы дерева (т.е. знать где класс, где цикл и т.д.), то можно загружать, скажем, .java, а сохранять как .pas и возможно, оно даже будет компилироваться и работать без дополнительного редактирования.
В общем, возможности открываются довольно широкие для создания действительно современного, прорывного IDE. Потом Embarcadero его купит для Delphi. А может и не Embarcadero.

Хотя это конечно куда сложнее и технологичнее, нежели аналог Notepad++ или Geany.

А в чем уникальность данного IDE?

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

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

полностью согласен
но в данном случае средство имеет конкретных пользователей и должно решать их текущие (и обозримые) проблемы
"прорывное" IDE - это развитие или совсем другой продукт

Mirage писал(а):Если стандартизировать узлы дерева (т.е. знать где класс, где цикл и т.д.), то можно загружать, скажем, .java, а сохранять как .pas и возможно, оно даже будет компилироваться и работать без дополнительного редактирования.

Такое уже было. Схемы на гибридных языках дракон сохраняются в другие языки, причём если в целевом языке нет оператора goto, то его приходится эмулировать. В паскале он есть, поэтому хотя бы процедурщина должна нормально транслироваться.

Сквозняк писал(а):Такое уже было. Схемы на гибридных языках дракон сохраняются в другие языки,

Дракон уже имеет классы?

stikriz писал(а):Дракон уже имеет классы?

А зачем ему классы? Дракон разработан для инженеров которые не умеют программировать но знают свою железку лучше программистов. Грубо говоря, чтобы нарисованную 2Д схему с формулами конвертнуть в модуль на паскале, классы, за исключением может быть TThread, не нужны, хватит процедурщины и гото. Подключить этот модуль с логикой к программе использующей классы, это задача уже программистов.

Классы в теории конвертируются но некроссплатформенно. Видел транслятор Win32 ассемблер --> паскаль.

Сквозняк писал(а):А зачем ему классы?

А зачем он вообще нужен программисту? Тем более, разговор идет о конвертации классов, циклов и т.д. А Вы тут с каким-то убожищем от человека, который считает, что думать плохо, опасно для жизни, и учит всех не думать. Вот он и не подумал, когда ваял дракон Есть UML - стандарт де-факто, достаточно проработаный, чтобы рисовать блок-схемы и делать заголовки. Так вот недопрофессионалы создают недохрень, чтобы потом своих студентов учить плохому. Кстати, есть куча программ, которые рисуют алгоритмы поведения физических приборов - и игры, и системы программирования контроллеров. Например, я видел систему аварийного запуска генератора в больнице, к ней идет программа.

Сквозняк писал(а):формулами конвертнуть в модуль на паскале, классы, за исключением может быть TThread, не нужны

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

stikriz писал(а):Вот он и не подумал, когда ваял дракон Есть UML - стандарт де-факто, достаточно проработаный, чтобы рисовать блок-схемы и делать заголовки.

Учитывая, что Дракон создавался, когда еще не было UML, то я бы не говорил, что Дракон какой-то плохой. Я сам Драконом не занимался и не скажу про его достоинства и недостатки.
Но про UML могу сказать что он скорее плохой, чем хороший. Беда любых графических (2D) изображений алгоритмов, хоть схемы, хоть диаграммы в том:
1. Что они громоздки. Без большого монитора или большого принтера - они неприменимы.
2. Они чрезмерно увлечены формализмом (как и любые порождения продуктов от Розы), и внешнее изображение определено формальными правилами, а не целесообразностью.

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

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

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

alexey38 писал(а):Учитывая, что Дракон создавался, когда еще не было UML

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

alexey38 писал(а):Но про UML могу сказать что он скорее плохой

Да, потому, что на нем невозможно думать. Кто-то может думать о чем-то серьезном на комиксах? На комиксах можно только дебилизирываться. UML помогает быстро войти в тему, понять что делают люди, чтобы потом уже продолжить. Это касается и общения с заказчиком, и общения с предыдущим программистом. И нужно только для больших проектов, когда сложность понимания оправдывает потраченого времени на формализацию. А программирование ментально. Оно подробно. Если подробностями засорять диаграмы, то будет еще более непонятно и громоздко. Это мое мнение. Диаграмма не может и не должно описывать алгоритмы во всех подробностях их реализации. Я использую диаграммы для описания бизнес-процессов крупными мазками.

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

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

alexey38 писал(а):Что касается идеи гибридный языков типа Дракона

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