Previous Entry Share Next Entry
фото

(репост) Re: Why does your $EDITOR bullshit?

Оригинал взят у stdray в Re: Why does your $EDITOR bullshit?
В комментариях к энторпрайз БАЙСИКУ 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 заметить сложно.


[dw]

  • 1
geekyfox March 21st, 2013
Поэтому для php/python/javascript IDE просто нахер не нужны.

_windwalker_ March 22nd, 2013
Видел я ошибки в питоне от того, что человек эклипсом пользовался. Тьфу.

sdfgh153 March 22nd, 2013
Абсолютно верное замечание: проверка типов и валидности — задача компилятора. Но это подстраховка для программиста, а не основная функция которая тащит за собой весь процесс разработки. Проще говоря не надо использовать автокомплит, подсветку синтаксиса и Live Issues, думай головой, а все эти чудесные проверки пусть делает компилятор в момент компиляции.

Serge Shikov March 22nd, 2013
Вы, пардон, над проектом один что-ли работаете?

sdfgh153 March 22nd, 2013
Нет, а как автодополнение влияет на то, что я не один работаю?
Я, как программист использующий чужой код обязан знать его интерфейс. Говнякать вслепую с автокомплита прямой путь к интересным багам.

Serge Shikov March 22nd, 2013
Очень просто. Если вас работает много - то вы по-определению плохо знаете свой проект. Обязан или нет - не влияет, все равно чужой код вы всегда знаете хуже. Или тратите на его изучение много времени.

Вслепую? Это почему еще? Хороший автокомплит давно уже понимает типы и сигнатуры методов и функций.

sdfgh153 March 22nd, 2013
И смысл интерфейса он тоже вам расскажет? Если вы внимательно читаете автокомплит, в чем разница с внимательным чтением интерфейса кода?

Serge Shikov March 22nd, 2013
Автокомплит - это (в том числе) удобный способ чтения документации.

Я собственно пытаюсь донести простую вещь:
> не надо использовать автокомплит ... думай головой
это чепуха. Думание и документация на то, что написал кто-то другой - это разные вещи в общем случае.

(Deleted comment)
sdfgh153 March 22nd, 2013
Обязан или нет - не влияет, все равно чужой код вы всегда знаете хуже.

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

wizzard0 March 22nd, 2013
Я приведу некоторый аргумент в сторону позиции Сергея, но отличающийся от нее.

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

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

Если я пишу сам - я могу херачить DSL'и транслирующиеся по нескольку метауровней в итоговый код, если пишет 3 человека - уже появляются какие-то conventions, если пишет 30+ - то фичи языков начинают активно запрещаться, иначе человек, ушедший в отпуск, тратит еще месяц на последующее "вьезжание в тему".

wizzard0 March 22nd, 2013
Еще есть совершенно разные виды кода - есть код "трудный" и "сложный", по-английски "complex" и "complicated" (но английские варианты я все время путаю), для трудного лучше супер-языки, для сложного - супер-IDE.

Трудный код - его мало, он нетипичный и, как правило, плохо поддается разбиению на модули. "Рожается" медленно и типично для этого нужны супер-гуру, 1-2 шт.
Сложный код - его много, но он плюс-минус однообразный, и не поддается уплотнению. "Рожается" быстро, но с кучей мелочей, типично параллелизуется на Х программистов, X>5.

Например, "написать движок построения планов к БД" - трудный код.

Написать экспортеры в Х форматов - сложный код.

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

nsinreal March 23rd, 2013
Мне вот интересно:
1) Неужто Naming Conventions у вас определенны на всем проекте (и сопутствующих либах, которые вы юзаете) настолько полно и логично, что вам никогда не приходится вспоминать как пишется имя той или иной функции?
2) И перегрузка методов у вас практически не используется, а если и используется, то для всех вариантов всех методов вы помните порядок следования параметров? Да даже без перегрузки у вас должно быть отличная память
3) Кстати, автодополнение используется так-же, что-бы ... автодополнять. Ну т.е. меньше писать букв.

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

sdfgh153 March 25th, 2013
Отвечаю:
1. Нет, не настолько определены. Мы просто внимательно читаем код.
2. Используется, мы просто внимательно читаем код. (Хотя если честно, то в основном мы пишем на Objective-C, тут перепутать порядок методов, эээ, проблематично)
3. Да, действительно, это медленнее. Зато надежнее. Меня не пугает перспектива напечатать вручную метод длиной 12-20 символов, я привык и не вижу тут трагедии. Ну да, это займет три секунды вместо одной. Но ведь я свое рабочее время трачу и куда менее толковыми способами. Ну вот например пишу этот комментарий или чай пью.

Еще раз: да, все это значительно (~ 40 минут в день) медленее, чем с автодополнением. Но результат мне нравится куда больше.

Про подсветку синтаксиса загадочно у вас получилось. Как она вообще связана с объемом проекта? Вы или видите стуктуру того, что на экране или не видите. Если вы ее видите только с подсветкой синтаксиса, значит у вас хреновая структура (или вы избаловлись, как было со мной), вот и все.

Если интересно, я писал почему отказался от подсветки синтаксиса: http://sdfgh153.livejournal.com/103433.html

С тех пор желания включить ее обратно не возникало. Независимо от объема проекта.

Edited at 2013-03-25 03:04 am (UTC)

zyxman March 22nd, 2013
Думаю, что основной затык, что сами редакторы пока еще пишутся в основном императивно и слишком много сил тратится на борьбу с системой.
То есть очевидно, что дизайн свою долю затрат ресурсов не отдаст ;) следовательно остается только дождаться, когда редакторы будут писать на системах вроде эрланга - тогда за счет лямбды станет изощренней логика, а за счет массированной распределенной обработки можно будет смириться с вычислительной сложностью сбора информации из крупного проекта.

max630 March 22nd, 2013
Я так и не очень понимаю смысла автодополнения в хаскеле, где почти всё может стоять почти везде, а тип может очень сильно поменяться (и остаться локально корректным!) от забытого аргумента или не того отступа.

  • 1
?

Log in

No account? Create an account