видать звезды не так сошлись, или проект ну очень большой, или комп ну очень слабый, или хз что еще. у меня редко бывають траблы, разве что на тестовых сборках. на релизных все нормально в целом
Да, в JetBrains считают что у программиста меньше 16Гб памяти не бывает. На 2-4Гб студия(проверял на 2010й) шустро бегает, а при установке решарпера превращается в черепаху скребущую лапами по НЖМД. Меня это не устраивает.
//для С++ лучшая приблуда - VisualAssist. который в отличии от продуктов JB не тормозит.
Написание кода 10-20% времени занимает, остальное под отладку и размышления
Ну вот у кого-то 10% на написание, остальные 90% - на размышление. Всё можно делать и в редакторе.
А вот ковыряться в отладке приходится по несколько часов(почему null-pointer-exception раз в 3 часа появляется?). Для этого IDE бесценно.
Эээ... ты сидишь в IDE 3 часа и ждешь, когда появится NPE? Я не знаю, как там в Яве, но в Си/Си++ в таких случаях обычно анализируется кора. Ну или можно заскриптовать gdb так, чтобы перехватывал сегфолт.
ты сидишь в IDE 3 часа и ждешь, когда появится NPE?
нет конечно. я останавливаю код, сморю содержимое переменных, откуда оно приходит и анализирую попивая чай. через часа 3 приходит в голову решение обычно.
Ну или можно заскриптовать gdb так, чтобы перехватывал сегфолт.
Это хорошо когда ошибка у тебя проявляется, а не у клиента на Сахалине(так что у вас даже рабочие часы не совпадают).
Ну или можно заскриптовать gdb так, чтобы перехватывал сегфолт.
Это хорошо когда ошибка у тебя проявляется, а не у клиента на Сахалине
Не понял, как интегрированный отладчик облегчает доступ к клиенту на Сахалине.
Я не против IDE и сам работаю в основном в Eclipse, но я вполне понимаю, как люди работают в текстовых редакторах, и преимущества printf-отладки тоже понимаю.
это я на заскриптовать отвечал и что на заскриптованный отладчик не помедитируешь так же как на код в IDE.
Пойнт скриптования в том, что на него не надо медитировать - отладчик сработал, выполнил скрипт, а дальше всё идет как обычно.
но я вполне понимаю, как люди работают в текстовых редакторах, и преимущества printf-отладки тоже понимаю.
пробовал js-код так писать. было противно. очень противно.
Это потому, что JS говно сам по себе. А когда отлаживаешь драйвер, возможность получить отладочную печать - это щастье, потому что бывают моменты, когда медитация и wetware emulation - это единственный способ отладки %)
Ctrl+O для nano
:w для vim
Вот примерно это я хотел сократить, не вдаваясь в детали, сколько раз Enter нажать и сколько Esc.
Кстати сочетания клавиш nano очень приятны для рук, ибо если долго работать левой рукой с контролом и c,v,s,w, то либо кисть начинает болеть, либо мизинец. (нужны две руки, присем левую подушечкой положить на клавишу, а правой даже не смещаться с положения слепой печати). Правда, и в Nano есть Ctrl W,R...
Правой рукой контрол жать неудобно, из за клавиш правее его.
Deleted ()
Последнее исправление: merhalak
(всего
исправлений: 1)
к сожалению да. остаётся разве что ждать, пока clion допилят хотя бы до такого же состояния, как собсна идею. ну или ждать, пока вижуалку на линаксы портируют
я имею в виду не только скорость. были кейсы(причём довольно простые), ломающие парсер. при этом, хотя у меня сам clion не тормозит после того как проект загрузится, взаимодействие с дебаггером лагает жутчайше(если сравнивать с идеей/вижуалкой). я даже не знаю, в gdb проблема, или в самом clion, но смотреть в нём stl-евские структуры можно только если у тебя много времени
я не понимаю высокоинтеллектуальные перлы типа «больше нигде нет редактора»
Просто ты малолетка. Все эти перлы про емакс, в который никак не встроят текстовый редактор, и вим, который бибикает и портит, это просто IT фольклор, давно всем хорошо известный.
Для больших проектов. Но опять же, проект очень большой (петабайты данных лопатит), но модули в нем очень decoupled и состоят из 5 файлов. Вот недавно написал отдельный микросервис на 1200 строк с тестами на С++. Это такой себе маленький квадратик в большой схеме
Все эти перлы про емакс, в который никак не встроят текстовый редактор, и вим, который бибикает и портит, это просто IT фольклор, давно всем хорошо известный.
спасибо огромное за информацию, запишу, чтоб не забыть. только это не делает фразу «нигде кроме ___ нет редактора» чем-то кроме религиозной проповеди либо глупой шутки.
а как ты дебагаешь в том же виме? голый гдб? а то я вот плагинов ваще никаких не нашёл для хорошего дебага. или в модулях, которые ты пишешь, он[дебаггер] не нужен?
Обычно действительно дебаггер не использую. Просто очень сильная модульность и обычно очень легко понять, даже по сообщениям логов, что не так. Там большинство кода - сообщение вошло, просканировал ФС, что-то прочитал, отослал 4 сообщения. Вот тебе и юнит-тест, а то и запустить на тестовых данных легко
ну да, с хорошими логами в большинстве случаев дебаггер действительно не нужен. я тут только что понял, что и мне дебаггер-то нужен только если балуюсь спортивным программированием
Например Java/C++ имеют низкую выразительность. Scala/Python имеют высокую выразительность кода.
Например Java/Scala/C# имеют прекрасные возможности для completion, так как код который может оказаться после курсора почти всегда можно вычислить и подсказать. В Python/Ruby - это не возможно, если вы внутри тела функции с аргументом a, то в общем случае понять что такое a - невозможно. С++ обладает современной библиотекой libclang, лучше которой мало кто справится с парсингом кода, но тем не менее слишком много неоднозначностей. Например если в C++ T - параметр шаблона, то по нему уже мало что можно подсказать, хотя например в Java могли бы быть ограничения на то, чем T может быть, например <T extends MyClass>, потому с С++ все дейсвительно качественно тяжелее.
Для языков высокой выразительности, но слабыми возможностями general purpose completion более выгодно использовать редактор или IDE с самыми мощными возможностями обработки текста. Тут редакторы вроде vim после определенного изучения становятся в разы более продуктивными чем Idea/Eclipse. В эту категорию идут JavaScript/Python/Ruby/C++. Для динамически типизируемых языков как IDE и редакторы играют на поле в котором нельзя победить. Для С++ есть libclang, который легко интегрируется в vim и в IDE, и врядле авторы IDE смогут предложить что-то значительно лучше или качественне распарсить С++ код.
Но когда язык статически типизирован и изначально разрабатывался с учетом completion, то более сложное IDE побеждает над редакторами. В эту категорию идут Java/Scala/C#. Редакторы можно научить подсказывать, но делается это с переменным успехом или путем запуска IDE в фоне (например eclim)
Я перешел на vim, потому что именно в нем проще писать на C++/Python, на которых я пишу сейчас. Более того, vim - программируемая среда, вместо того чтобы качать исходники IDEA и писать плагин с кучей boilerplate (а то и вообще ныть что кто-то не написал его для меня), я могу почти однострочечником в .vimrc сделать что-то совершенно уникальное, нужное только мне. А потом хранить это вечно на github и переносить от машины к машине.
Если мне прийдется вернуться на Java/Scala, но я без проблем буду работать в IDEA
Можно ему дать в точности тот же .vimrc который на удаленных машинах? Можно работать в ssh+tmux бегая между зданиями со своего хромбучека за 300 баксов, постоянно открывая и захлопывая крышку, на тачке с 32ГБ памяти?
По основной работе иногда приходится редактировать крупные текстовые файлы, при чём иногда бывают необычные потребности (вставить символ или слово в некоторую позицию каждой строки), в другой ОС использоваk notepad++, в линуксах никак не мог найти достойного аналога, пока не наткнулся на vim. В первый раз, как и многие, не смог выйти из vim. Но почитав и подготовившись, я нашёл в нём весь необходимый для редактора функционал и даже больше. А когда возникает необходимость написать небольшую программу на С, то vim с ycm вполне хватает. Так и получается, что я использую vim для разных задач увеличивая объём знаний о нём и умение эти знания применять. Подозреваю, что если освоить весь этот функционал vim, можно действительно быстро и удобно набирать текст(код). Но проще, конечно, «не понимать».
рано или поздно когда нужно будет писать что-то больше и в команде, придет понимание что даже часы велосипедирования вима не дадут тот эффект, что дает иде из коробки.