Re: Why does your $EDITOR bullshit?
Mar. 21st, 2013 11:59 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
stdrayВ комментариях к энторпрайз БАЙСИКУ proofit404 дал линк на свой пост, где рассказывает, про негативный опыт со средами разработки для Haskell, ну и предлагает выпилить люк, создав хитрющую прослойку между редакторами и конпелятором.
Я так полагаю, дело вовсе и не в редакторе и не в способах хранения цветов и автокомлитов каких. Если говорить о компилируемых языках программирования, то никто не может знать о программе больше чем сам компилятор. И вопрос упирается в то, проектировался ли компилятор с учетом работы в режиме IDE или нет. Если да, то написание качественной интеграции большая, но понятная задача. Надо лишь выбрать IDE, изучить документацию и нарисовать плагин, который просто будет заниматься вызовами API компилятора и среды разработки.
При этом "проектировался" означает не только умение принимать / возвращать какие-то данные, но и работать в разных режимах. Потому как шевелиться все это должно достаточно быстро, а если какой-нибудь компилятор Haskell сначала начнет типизировать 100500 файлов проекта, потом займется оптимизацией, позвав на помощь LLVM-бекенд, то ничего хорошего из этого точно не получиться. Выходит, что в режиме IDE ему нужно лишь распарсить и типизировать AST, опуская непосредственную компиляцию, или компилируя без оптимизаций, если редактируемый проект у кого-то в зависимостях и есть потребность в метаинформации сборки (для языков по типу C#). Если язык имеет макроподсистему, то информацию о режиме работы компилятора надо пихать и туда. Также не считаю, что возможно реализовать какой-то stateless протокол обмена между компилятором и IDE, сделав компилятор сервисом или вроде того, поскольку работы у него действительно много. И если при каждом изменение текста гнать ему все файлы проекта для обработки - все будет весьма печально. Потому компилятору нужен стейт, чтобы иметь возможность кешировать результаты своей работы.
Это что касается простых технических решений. Кроме них еще и есть более спорные моменты в дизайне самого языка. Если в C# границей работы компилятора является текущая сборка, а для подключаемых библиотек можно просто брать и выдирать метаинформацию для использования,то в Haskell нужны исходники этих библиотек (не совсем так см. обсуждение в комментах), а на крупных проектах это уже задача совсем другой вычислительной сложности (хотя они как-то решают этот вопрос). Или взять вывод типов, в Nemerle он локальный, потому что стоит искусственное ограничение (алгоритму вывода все равно на каком уровне работать), отключающее вывод на глобальном уровне, поскольку уже небыстрый компилятор (в 5-10 раз медленнее компилятора C#) замедлится до состояния "можно пойти попить чайку". Это тоже надо учитывать, ведь какие-то простенькие автокомплиты и цвета - это все хорошо, но наибольшую ценность представляют типы, поскольку именно на них основано полезное автодополнение, выявление ошибок, переходы к определению и так далее. Этому процессу нельзя быть медленным.
Так же есть сомнения относительно разного рода промежуточных форматов вроде ctags/etags. Я ими не пользовался, да и разработкой интеграции никогда не занималсяно осуждаю. Просто, на мой взгляд, нерасширяемый формат - это лишнее и узкое место, а xml тащить, ммм... Лишнее потому что, я думаю, разным языкам понадобится гонять разную информацию и по-разному ее представлять, потому, по-большому счету, ничего обобщить не получится и для каждой конкретной пары ЯП+IDE надо пилить отдельную реализацию. По этим же причинам это место является узким, поскольку одних координат может быть недостаточно. А с точки зрения производительности вызывает сомнения текстовый формат передачи, особенно через файлы.
Понятно, что подход затачивания компилятора для работы в режиме IDE не единственный. Например, существуют IDE для интерпретируемых языков (которые правда уже давным-давно конпеляцией в байт-код обзавелись) или ReSharper, который самостоятельно занимается анализом кода. Но это достаточно дорогой путь, на мой взгляд, поскольку люди сталкиваются с очень объемными и сложными задачами, которые невозможно решать за бесплатно в свое свободное время. Да и плохо это вписывается в концепцию повторного использования имеющихся наработок. Или вот ребята, которые работают над проектом N2 имеют какие-то мысли по автоматизации процесса создания интеграции для языков программирования. Но пока конкретики немного. Зато есть понимание, что этот подход основывается именно на создании компиляторов изначально спроектированных для поддержки работы в режиме IDE.
Написание качественных сред разработки сложная задача, но решаемая при должном старании и понимании необходимости. А то есть же изрядное количество непоследовательных контрамотов, которые сначала громогласно объявляют, что IDE НИНУЖНА, а потом стараются изо всех сил собрать тоже самое из некачественных подручных материалов. Вообще, я думаю, что самым важным моментом является то, что кроме получения негативного опыта с выводом "все козлы", перед тем как предлагать какие-то свои варианты, необходимо изучить и позитивные решения. Но тут уже личное отношение всплывает, что если пишешь ненавистный код на ненавистной джаве, то и достоинства какой-нибудь IDEA заметить сложно.
Я так полагаю, дело вовсе и не в редакторе и не в способах хранения цветов и автокомлитов каких. Если говорить о компилируемых языках программирования, то никто не может знать о программе больше чем сам компилятор. И вопрос упирается в то, проектировался ли компилятор с учетом работы в режиме IDE или нет. Если да, то написание качественной интеграции большая, но понятная задача. Надо лишь выбрать IDE, изучить документацию и нарисовать плагин, который просто будет заниматься вызовами API компилятора и среды разработки.
При этом "проектировался" означает не только умение принимать / возвращать какие-то данные, но и работать в разных режимах. Потому как шевелиться все это должно достаточно быстро, а если какой-нибудь компилятор Haskell сначала начнет типизировать 100500 файлов проекта, потом займется оптимизацией, позвав на помощь LLVM-бекенд, то ничего хорошего из этого точно не получиться. Выходит, что в режиме IDE ему нужно лишь распарсить и типизировать AST, опуская непосредственную компиляцию, или компилируя без оптимизаций, если редактируемый проект у кого-то в зависимостях и есть потребность в метаинформации сборки (для языков по типу C#). Если язык имеет макроподсистему, то информацию о режиме работы компилятора надо пихать и туда. Также не считаю, что возможно реализовать какой-то stateless протокол обмена между компилятором и IDE, сделав компилятор сервисом или вроде того, поскольку работы у него действительно много. И если при каждом изменение текста гнать ему все файлы проекта для обработки - все будет весьма печально. Потому компилятору нужен стейт, чтобы иметь возможность кешировать результаты своей работы.
Это что касается простых технических решений. Кроме них еще и есть более спорные моменты в дизайне самого языка. Если в C# границей работы компилятора является текущая сборка, а для подключаемых библиотек можно просто брать и выдирать метаинформацию для использования,
Так же есть сомнения относительно разного рода промежуточных форматов вроде ctags/etags. Я ими не пользовался, да и разработкой интеграции никогда не занимался
Понятно, что подход затачивания компилятора для работы в режиме IDE не единственный. Например, существуют IDE для интерпретируемых языков (которые правда уже давным-давно конпеляцией в байт-код обзавелись) или ReSharper, который самостоятельно занимается анализом кода. Но это достаточно дорогой путь, на мой взгляд, поскольку люди сталкиваются с очень объемными и сложными задачами, которые невозможно решать за бесплатно в свое свободное время. Да и плохо это вписывается в концепцию повторного использования имеющихся наработок. Или вот ребята, которые работают над проектом N2 имеют какие-то мысли по автоматизации процесса создания интеграции для языков программирования. Но пока конкретики немного. Зато есть понимание, что этот подход основывается именно на создании компиляторов изначально спроектированных для поддержки работы в режиме IDE.
Написание качественных сред разработки сложная задача, но решаемая при должном старании и понимании необходимости. А то есть же изрядное количество непоследовательных контрамотов, которые сначала громогласно объявляют, что IDE НИНУЖНА, а потом стараются изо всех сил собрать тоже самое из некачественных подручных материалов. Вообще, я думаю, что самым важным моментом является то, что кроме получения негативного опыта с выводом "все козлы", перед тем как предлагать какие-то свои варианты, необходимо изучить и позитивные решения. Но тут уже личное отношение всплывает, что если пишешь ненавистный код на ненавистной джаве, то и достоинства какой-нибудь IDEA заметить сложно.