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
Вы действительно думаете, что 4 секунды разницы имеют смысл в программировании?

Serge Shikov March 22nd, 2013
Эти 4 секунды приходятся на одно нажатие на кнопку. Не на каждое - но на некоторые. Таких нажатий в день может быть тысячи. Это во-первых. А во-вторых, после фильтрации я получу список скажем из 10 элементов, релевантных в этом контексте. А не из 1000. Вот и еще лишние 10 секунд набежали.

sdfgh153 March 22nd, 2013
Я привел конкретные цифры: 40 минут в день. Я готов на такие жертвы ради продуманного кода :)

sdfgh153 March 22nd, 2013
автокомплит уже отфильтровывает нерелевантную инфу, которую не надо читать

Релевантную он тоже отфильтровывает, кстати.

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

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

Serge Shikov March 22nd, 2013
> А интерфейс усвоить не так уж и сложно.
Ит депендс.

Ну вот живой пример: есть задача сделать отчет. Инструмент - Eclipse BIRT. Выбирал его не я, но это не принципиально, потому что сильно лучше все равно ничего нету. API его большой, плохо описанный, и в меру кривоватый. Работать с ним нужно прямо сейчас. Вы что предпочитаете - редактор с автокомплитом, где про каждый из методов/функций/объектов прямо написано, что он делает, какая у него сигнатура, и для чего он нужен, или отдельную документацию (в виде книжки это страниц 700), где это же все описано?

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

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

И вот для чего: довольно часто вопросом который ведет разработчика использующего чужой код является «А нет ли тут вот такого метода?». Очень часто оказывается, что метод есть, но не поняв интерфейса в целом можно наломать дров, потому что этот метод запросто сделает не вполне то, что программист про него думал.

Автокомплит увеличивает риск «А нет ли тут»-драйвен девелопмента, потому что снимает острую необходимость понимания устройства модуля в целом.

То есть усвоение API и есть то, что я называю думаньем головой.

Serge Shikov March 22nd, 2013
> То, что вы описываете это и есть изучение интерфейса.
Именно. Или вообще чужого кода - если мне потом его сопровождать.

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

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

sdfgh153 March 22nd, 2013
Поэтому я предпочитаю не просто IDE с автокомплитом, но и с переходом по клику туда, где на самом деле находится этот метод.

Это вообще-то совсем не всегда возможно. У меня процентов 40 библиотек закрыты изначально.

В моих проектах за последние лет 10 как правило не было физической возможности полного понимания.

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

Serge Shikov March 22nd, 2013
Ну, когда я говорю "предпочитаю" - это не значит, что код всегда видно. Но что я точно знаю - это то, что интерфейс большинства языков далеко не полностью описывает семантику методов. Тот же факт отсортированности списка, например - это или нельзя сделать частью контракта, или очень редко делается его частью.

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

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

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

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

sdfgh153 March 22nd, 2013
Ну я точно так же "по ощущениям" могу сказать, что количество плохого кода в проекте тоже кореллирует с навороченостью IDE. Доказать не могу только :)

Умные средства тестирования и профилирования я всецело одобряю, кстати.

Serge Shikov March 22nd, 2013
По своим ощущениям могу сказать, что тупые IDE тоже не всегда дают на выходе заведомо хороший код. Зато времени на него уходит намного больше всегда.

sdfgh153 March 22nd, 2013
> намного больше всегда

По своим ощущениям могу сказать, что после отказа от IDE я стал работать на 40 минут в день больше :) То есть из 8 рабочих часов я программирую не 3, а 3:40-4 часа в день.
Ужасная потеря времени, конечно.

geekyfox March 22nd, 2013
Что, и для Objective-C XCode не нужен? ;-)

sdfgh153 March 22nd, 2013
Я код пишу в Acme, компилирую, дебажу и профилирую в икскоде, тут без вариантов.

geekyfox March 22nd, 2013
А. Я ещё помню те времена, когда у тебя XCode с автокомплитом был обязателен и тоже БЕЗ ВАРИАНТОВ!!!111

Долгая память хуже чем сифилис, конечно ;-)

sdfgh153 March 22nd, 2013
Я тоже это помню и не скрываю, кстати :)

geekyfox March 22nd, 2013
А вообще это всё language-dependent, конечно.

Вот например на своей нынешней работе я за год так и не удосужился поставить себе какое-либо ide, поскольку тут php/python/js и vi+grep+awk+bash закрывают все мыслимые потребности на 110%

А зато когда мне как-то приспичило покодить на джаве, то уже где-то к пятому-седьмому классу я полез расчехлять эклипс ПАТАМУШТАНУЭТОЖЕНЕВОЗМОЖНО

geekyfox March 22nd, 2013
всё так, чё

Serge Shikov March 22nd, 2013
js? Не знаю, не знаю. IDEA настолько лучше других в этом вопросе, что даже сложно сравнивать.

geekyfox March 22nd, 2013
Я не посягаю на ваше право использовать те инструменты, которые больше нравятся/подходят. Расслабтесь.

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

sdfgh153 March 22nd, 2013
Ну чего гадать-то, это был C/Objective-C и XCode/AppCode :-)

geekyfox March 22nd, 2013
Ваше соображение - не language agnostic.

Для джавы оно верно, для пхп/питона - нет.

Serge Shikov March 22nd, 2013
Ну, можно на все языки не обобщать. Нивапрос. Вон ниже написано было:

> Я так и не очень понимаю смысла автодополнения в хаскеле, где почти всё может стоять почти везде,
Когда это так, то да, смысла мало. Чем больше данных и умнее комплит - тем очевидно больше пользы.

justy_tylor March 22nd, 2013
Меня вот смущают IDE, ориентированные на "инструменты рефакторинга" и прочую идеа-эклипсятину. Ибо подразумевают много рефакторинга в процессе разработки, а это сильно нездоровое явление. По отдельности фишки полезные, а в UI витрина психушки получается.

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

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

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

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

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

wizzard0 March 22nd, 2013
Вынесу-ка я это в отдельный пост

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