Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 380
IDE — необходимость, независимо от нашего желания.
Необходимость, ага. У меня половина коллег кодит в виме. Многие в саблайме. Некоторые виндусятники в нотпаде++.
В IDE — меньшинство знакомых (почти только джависты). Вот такая вот необходимость.
А на чём кодите (Вы и коллеги/знакомые), если не секрет?
C/С++, python, Go, js — масштабно, ну и так, балуюсь на всем по мелочи.
Я себе для веба даже поделку под ST сделал: packagecontrol.io/packages/Color%20Highlighter.
Я себе для веба даже поделку под ST сделал: packagecontrol.io/packages/Color%20Highlighter.
C/С++, python, Go, js — масштабно, ну и так, балуюсь на всем по мелочи.
По-моему ни для одного из этих языков нет IDE, в которой бы сносно работал рефакторинг (более сложный, чем rename). А без рефакторингов IDE это действительно просто текстовый редактор с подстветкой, обвешанный парой плагинов. Отсюда и мнение что IDE не нужно.
Отвечу за С++:
Вещи типа автоматического включения инклюдов, выноса кода в метод, переименования сущностей, реализация стабов методов интерфейса, навигация по коду, подсветки, подсказок, автодополнения — работают очень хорошо.
- Visual Studio + Visual AssistX\Resharper C++
- CLion
- QtCreator
Вещи типа автоматического включения инклюдов, выноса кода в метод, переименования сущностей, реализация стабов методов интерфейса, навигация по коду, подсветки, подсказок, автодополнения — работают очень хорошо.
А Вы код ядра пробовали в CLion открыть и что-нибудь попытаться написать новое? И завязка на CMake имхо сильно сковывает, когда куча проектов на обычном gnu make.
И завязка на CMake имхо сильно сковывает, когда куча проектов на обычном gnu make.
Хм, а в чем конкретно вас сковывает cmake?
Тем, что надо прописывать ВСЕ исходники со всеми подключаемыми либами. Все как в make, но вот ни о каком автодополнении и прочих сладостях CLion и думать не приходится, пока все это не опишешь в конфиге. И по маске добавить нельзя. Вот честно, искал решение и не нашел, все уверяют, что надо четко каждый файл прописывать. А на больших проектах, где 100500 файлов, типа squid, для того чтобы чтото поправить, надо с нуля сборку написать. Ну это разве нормально?!
Честно говоря не понял о чем вы… писать cmake-скрипты и проще и быстрее, чем обычные make'и… а вот то, что в CLion оно работает как-то не так… ну это проблема этой IDE, а не cmake'а.
Честно говоря не понял о чем вы…
О том, что нужно переписывать всю систему сборки только ради того, чтобы воспользоваться IDE. У нас, например, свой build-framework, основанный на make, который во многом удобнее изкоробочного cmake. У некоторых коллег есть лицензия CLion, но они так и не смогли его эффективно использовать — код компилируется на удалённом сервере + система сборки — не cmake.
Написать — проще. Портировать существующую сборку с нуля на XXX — бывает архисложно. А делать это, только, что бы открыть код в IDE вообще моветон. В QtC это элегантно решили.
Почему архисложно? В большинстве случаев под платформу XXX уже есть cmake и можно собираться нативно на таргет-устройстве. А для кросскомпиляции достаточно написать правильный toolchain файл. При этом голые make'и под банальный Windows уже придется собирать либо под MinGW, либо переписывать все на nmake, что не очень интересно.
Вы пытаетесь подменять понятия: в ответе на habrahabr.ru/post/265197/#comment_8545795 и на мой комментарий выше.
Объясняю: речь про CLion. Он может сейчас эффективно работать только с CMake проектами. Это и есть завязка — завязка CLion на CMake. Вы же начинаете про скованность самого cmake. Да никого он не сковывает, просто есть куча проектов которые его не используют. И работать с ними в CLion — сложно и неудобно.
Теперь про портирование. Ядро Linux не использует CMake для сборки. Попробуйте портировать с kbuild на CMake — это и есть портирование. Да, если проект использует уже CMake, то написать грамотный тулчейн и вуаля. Главное, что бы кривожопость некоторых авторов правил в CMakeLists.txt не приводила к мукам. А такие криворучки попадаются на удивление часто.
Вроде всё по полочкам разложил.
Объясняю: речь про CLion. Он может сейчас эффективно работать только с CMake проектами. Это и есть завязка — завязка CLion на CMake. Вы же начинаете про скованность самого cmake. Да никого он не сковывает, просто есть куча проектов которые его не используют. И работать с ними в CLion — сложно и неудобно.
Теперь про портирование. Ядро Linux не использует CMake для сборки. Попробуйте портировать с kbuild на CMake — это и есть портирование. Да, если проект использует уже CMake, то написать грамотный тулчейн и вуаля. Главное, что бы кривожопость некоторых авторов правил в CMakeLists.txt не приводила к мукам. А такие криворучки попадаются на удивление часто.
Вроде всё по полочкам разложил.
Ничего себе поделка, топ100 значок имеет)))
del.
Вообще, я ни в коем случае не говорю, что ИДЕ — отстой, не пользуйтесь ИДЕ. Просто есть неопровержимые доказательства отсутствия необходимости и факта первостепенности именно нашего желания.
почти только джавистыВот, кстати, да — в Java без IDE практически никак. Нет, конечно, можно программировать на Java и в редакторе, даже не в FAR с подсветкой синтаксиса, а вообще в Notepad без плюсов, но это экстрим, и так можно писать только если скорость написания и читаемость кода не волнует и рефакторить и «облагораживать» код не собираются. Java вообще интересный язык в этом плане — как будто настроена на то, чтоб извлекать пользу из IDE по максимуму. Наверное, из-за строгой типизации и изначально безопасного кода.
С Java всё весьма просто объясняется :) Из-за указанной вами строгой типизации и кучи стандартов/договоренностей, принятых в языке, которые не только упрощают разработку, но и помогают избежать кучи ошибок, на Java пишутся программы такого масштаба и сложности, который часто и не снился большинству других языков. Привет из Java Enterprise, в котором миллион строк кода — небольшая программа. Причем я одно время такую рограмму разработал и целый год поддерживал в паре с еще одним разработчиком. Вдвоем за 3 месяца написали, вдвоем год улучшали. Почти ни на одном другом языке такое даже не снилось (вероятно, конкуренцию могут составить C#, ruby и, возможно, python, но про последний — сомневаюсь).
А в проектах такого размера без IDE с ее быстрым контекстным поиском, автодополнением, переходом от одного куска кода к другому в один клик и т. п. — не обойтись.
А для C++, кстати, весьма неплох eclipse. Особенно для гибридных проектов C/C++ + Java. Там вообще пока альтернатив нет. Он, конечно, Си понимает хуже, чем родную Java, которую даже компилирует сам, вообще без участия javac, но всё равно неплохо.
А в проектах такого размера без IDE с ее быстрым контекстным поиском, автодополнением, переходом от одного куска кода к другому в один клик и т. п. — не обойтись.
А для C++, кстати, весьма неплох eclipse. Особенно для гибридных проектов C/C++ + Java. Там вообще пока альтернатив нет. Он, конечно, Си понимает хуже, чем родную Java, которую даже компилирует сам, вообще без участия javac, но всё равно неплохо.
У нас в команде из 10 человек, все пользуются исключительно PHPStorm.
Те кто предпочитают vim, notepad — значит такие программисты или мазохисты, или времени бесконечно.
C IDE процесс разработки превращается в рай и время на разработку продукта сокращается во много раз.
Те кто предпочитают vim, notepad — значит такие программисты или мазохисты, или времени бесконечно.
C IDE процесс разработки превращается в рай и время на разработку продукта сокращается во много раз.
Или они достаточно квилифицированны. Vim даёт невероятный прирост скорости.
Чтобы изучить PHPStorm тоже надо время.
Чтобы изучить PHPStorm тоже надо время.
vim дает прирост скорости?
Уж по мне так sublime интереснее.
Ну и vim надо еще изучать, или хотя бы переписать все хоткеи как в популярных редакторах.
Какой бы программист не был, с IDE он все равно будет быстрее писать код, видеть все ошибки и т.д. Он будет погружен полностью в проект, чувствовать каждый кусочек. Тысячи файлов должны быть как единый организм, а не как куски не пойми чего.
Вы ведь должны понимать, что скорость и качество, это главное в нашей работе, если конечно вы работаете не на себя.
P.S.
Для работы с PHP использую исключительно IDE PHPStorm.
Для работы с Go — sublime
Уж по мне так sublime интереснее.
Ну и vim надо еще изучать, или хотя бы переписать все хоткеи как в популярных редакторах.
Какой бы программист не был, с IDE он все равно будет быстрее писать код, видеть все ошибки и т.д. Он будет погружен полностью в проект, чувствовать каждый кусочек. Тысячи файлов должны быть как единый организм, а не как куски не пойми чего.
Вы ведь должны понимать, что скорость и качество, это главное в нашей работе, если конечно вы работаете не на себя.
P.S.
Для работы с PHP использую исключительно IDE PHPStorm.
Для работы с Go — sublime
Просто Вы не знаете vim, ничего переписывать там не надо, потому что в vim'е нет хоткеев в привычном понимании этого слова.
Кстати, я тоже использую PHPStorm, но с плагином IdeaVim.
Кстати, я тоже использую PHPStorm, но с плагином IdeaVim.
Когда пользуюсь vim, всегда использую простые хоткеи, тот же shift+ZZ or shift+ZQ.
Значит есть хоткеи, просто они совершенно отличны от всего софта.
Значит есть хоткеи, просто они совершенно отличны от всего софта.
Вот так всегда… Как только кто-то говорит, что IDE лучше чем vim/emacs, потому что — 1,2 и 3, контраргумент — «вы не знаете vim!»… Аргх
Потому что это пустой спор, в нём не нужны аргументы.
По мне, в IDE есть редактор текста и он проигрывает как редактор и VIM и Emacs.
Для себя я решил всё проще: я работаю в IDE, но когда надо что-то отредактировать, я нажимаю горячую клавишу и оказываюсь в VIM, выполняю то, что хотел, и снова оказываюсь в своей IDE.
Для меня это оказалось гораздо комфортней, чем отсутствие средств IDE в редакторе, или отсутствие нормального редактора в IDE.
По мне, в IDE есть редактор текста и он проигрывает как редактор и VIM и Emacs.
Для себя я решил всё проще: я работаю в IDE, но когда надо что-то отредактировать, я нажимаю горячую клавишу и оказываюсь в VIM, выполняю то, что хотел, и снова оказываюсь в своей IDE.
Для меня это оказалось гораздо комфортней, чем отсутствие средств IDE в редакторе, или отсутствие нормального редактора в IDE.
Какой бы программист не был, с IDE он все равно будет быстрее писать код, видеть все ошибки и т.д.
Не нужно голословных заявлений ;)
Про PHP не скажу. Про Java скажу. Посмотрел бы я, как вы в Vim будете анализировать и разбираться в проекте классов так на 100-150. На одно только переключение и поиск имплементаций интерфейсов, например.
Использование Vim при наличии продвинутой IDE говорит либо о том, что вы — пожилой специалист с закостенелыми привычками, которому трудно изучить новый инструмент, либо, что вы — студент, который чувствует себя более уверенно, работая в текстовом редакторе, из которого сверстники даже выйти не могут без его помощи (понты же!), либо человек, который просто не стремится выжать из окружения максимум возможностей. Очевидно, что среда, заточенная под конкретный ЯП, будет и удобнее, и эффективнее. Но загвоздка в том, что ее надо настраивать, изучать (а современные IDE сложны), а это — лень. А без адекватной настройки она — да — будет скорее мешать, увы.
Использование Vim при наличии продвинутой IDE говорит либо о том, что вы — пожилой специалист с закостенелыми привычками, которому трудно изучить новый инструмент, либо, что вы — студент, который чувствует себя более уверенно, работая в текстовом редакторе, из которого сверстники даже выйти не могут без его помощи (понты же!), либо человек, который просто не стремится выжать из окружения максимум возможностей. Очевидно, что среда, заточенная под конкретный ЯП, будет и удобнее, и эффективнее. Но загвоздка в том, что ее надо настраивать, изучать (а современные IDE сложны), а это — лень. А без адекватной настройки она — да — будет скорее мешать, увы.
Но загвоздка в том, что ее надо настраивать, изучать (а современные IDE сложны), а это — лень. А без адекватной настройки она — да — будет скорее мешать, увы.
Интересно, что большинство сторонников IDE здесь в комментариях придерживаются как раз мнения, что настраивать нужно «редактор».
Настройка настройке — рознь. Есть такая категория пользователей, которые готовы написать сто консольных команд и попроавить 50 строк в конфиг-файлах, но пассуют перед простым окошком «Properties». Просто так устроен их мозг, что GUI он не воспринимает. Я собственными глазами видел пару таких разработчиков. Они мучались и «жрали кактус», долго пытаясь превратить vim в недоделанный eclipse. И в итоге, когда я им показывал, что чтобы обновить список импортов во всем проекте, надо дважды кликнуть мышкой по менюшке, кривились: «как же так! серьезные программисты не пользуются мышью!»
На мой взгляд, основу такого отношения (в случае Java) закладывает снобизм. Человек не стремится решать задачу эффективно. Он стремится решать ее красиво. В смысле — красиво выглядеть в процессе решения. Это — психология, как я думаю. Рациональные доводы здесь ни при чем.
На мой взгляд, основу такого отношения (в случае Java) закладывает снобизм. Человек не стремится решать задачу эффективно. Он стремится решать ее красиво. В смысле — красиво выглядеть в процессе решения. Это — психология, как я думаю. Рациональные доводы здесь ни при чем.
И еще — про «долгую настройку». Я тут уже в комментах где-то писал, что по моим критериям «долгая настройка» — это полчаса-час после установки IDE. При условии того, что проект сложный и реально нуждается в этой долгой настройке. А ответил я это человеку, который сказал, что он…
Вот этот комментарий: habrahabr.ru/post/265197/#comment_8545391
Просто несколько разные масштабы времени соответствуют в нашем сознании понятию «долгая настройка».
Вот этот комментарий: habrahabr.ru/post/265197/#comment_8545391
Просто несколько разные масштабы времени соответствуют в нашем сознании понятию «долгая настройка».
Т.е. изучать и настраивать вим им не лень, а идешку они не осилят? Ну, возможно, мышкой будут по кнопкам промахиваться.
Вообще Ваш комментарий довольно оскорбителен и категоричен.
Вообще Ваш комментарий довольно оскорбителен и категоричен.
изучать и настраивать вим им не лень, а идешку они не осилят?
Прочтите мой предыдущий комментарий, пожалуйста. Краткий ответ: да, не осилят, потому что недостаточно мотивации. Не хотят они ее осиливать — она не соответствует их чувству прекрасного.
Вот я, к примеру, люблю Eclipse и не люблю Idea. С эстетической точки зрения. Рациональных аргументов в пользу того или другого почти нет — просто это две разных «культуры» разработки на Java. По функционалу они близки, поэтому я долгое время имел возможность выбирать ту, которая мне по душе и не чувствовать себя отстающим.
Но сейчас мне «по долгу службы» пришлось влезть внутрь IDE — делаем плагины для Android Studio — и тут уже, увы, приходится изучать Idea и пользоваться ею. Я мог бы до конца «стоять на своем» и упорно всё кодить в Eclipse, но я лучше буду знать обе среды в равной степени — тогда у меня будет больше аргументов при «холиварах» ;)
А если серьезно, то ничего оскорбительного, на самом деле, я сказать не хотел. В основном, как и везде, программисты — адекватные люди, которые выбирают инструмент к задаче. Но бывают, согласитесь, отдельные «упоротые» индивиды, которым не важно, что делать — лишь бы не учить эти мерзкие кнопочки-окошечки. Вот про эту категорию я и высказывался.
Привычка. У меня сейчас похожая ситуация с Visual Studio, но там ReSharper есть, не так больно.
Я считаю что есть только один критерий оценки — время жизни. Если в редакторе и ИДЕ одинаковый результат получается за разное время, то победитель тот, у кого это время ниже. И ИДЕ значительно чаще дает этот выигрышь по времени. Ничего не ценно так, как время разработки (опять же, при всех остальных прочих равных, подразумевается что код на выходе идентичный). Даже самая последняя ИДЕЯ и Вебшторм на многомегабайтных проектах запускается за 5 секунд на далеко не свежем компьютере, а если это не так, ну это же ваш рабочий инструмент, вы им зарабатываете деньги и не можете обеспечить себе комфортное рабочее место?
А про поддержку CSV, XML, и тд в ИДЕ это вообще отдельная история. ИДЕ не только обычно поддерживают их лучше, но и понимают семантику, могут поставить перекрестные ссылки и дополнять нужные ключи, как например .properties в java или свякзки angular.js и HTML, все это гарантированно экономит время, и вспоминания, и навигации.
Практически единственный момент (который тоже не всегда применим), это когда необходимо поменять что-то на уже рабочем сервере. Но для многих языков это невозможно — нужна перекомпиляция, или подход с деплоем не позволяет так просто пойти на сервер и менять файлы. В остальных всех случаях у редакторов нет никаких шансов перед ИДЕ (стоимость не берем во внимание).
Кроме того, ИДЕ это просто продолжение идеи редактора, а не паралельная ветвь эволюции. Ведь редактор с пониманием семантики русского языка становиться сразу же ИДЕ русского языка. Почему бы им не пользоваться при наличии?
А про поддержку CSV, XML, и тд в ИДЕ это вообще отдельная история. ИДЕ не только обычно поддерживают их лучше, но и понимают семантику, могут поставить перекрестные ссылки и дополнять нужные ключи, как например .properties в java или свякзки angular.js и HTML, все это гарантированно экономит время, и вспоминания, и навигации.
Практически единственный момент (который тоже не всегда применим), это когда необходимо поменять что-то на уже рабочем сервере. Но для многих языков это невозможно — нужна перекомпиляция, или подход с деплоем не позволяет так просто пойти на сервер и менять файлы. В остальных всех случаях у редакторов нет никаких шансов перед ИДЕ (стоимость не берем во внимание).
Кроме того, ИДЕ это просто продолжение идеи редактора, а не паралельная ветвь эволюции. Ведь редактор с пониманием семантики русского языка становиться сразу же ИДЕ русского языка. Почему бы им не пользоваться при наличии?
Без редактора тоже не очень хорошо. IDE не сильно заточены, к примеру, для открытия огромных файлов.
Идея на работке спокойно открывает файлы в 6к+ строк, работает мгновенно, навигация мгновенная
Огромные файлы — это 100 мегабайт, 1200 мегабайт. Всякие CSV, XML выгружаемые.
Вот тут-то уже IDEA не справится. И Atom, и Sublime тоже спасуют. Только vim и спасает в таких случаях.
Вот тут-то уже IDEA не справится. И Atom, и Sublime тоже спасуют. Только vim и спасает в таких случаях.
ИМХО, файлы такого размера не открывать надо, а запросы по ним гонять через всякие grep, а лучше — через инструменты, предназначенные для этих конкретных файлов. Слабо себе представляю что вменяемого можно сделать открыв 100-мегабайтный текстовый файл.
Как то на работу принесли огромедный файл выгрузки из одной известной системы похозяйственного учета. Содержимое этого файла было нам не известно, но его нужно было подготовить к загрузке в базу данных. Как вы бы предложили «гонять по нему через всякие grep» даже не взглянув на содержимое?
head -n20 ogromenny.txt
неа, там все в 1 строку. XML знаете ли. Да и первые хз сколько байт там были заполнены не нужной нам в базе инфой.
head -c 2000 file.xml
~$ xmllint --format --recover ogromenny.xml 2>/dev/null | head -n20
А чем хуже: vim ogromenny.xml — ?
А зачем вообще его читать в текстовом редакторе? Загрузите его сразу Xml-парсером любимого языка. Скажем, я бы открыл его парсером Java. А потом включил режим отладки и в окошке Watch (слыхали?) писал бы запросы на вложенные конструкции, изучал бы семантику, правил код чтения… что там вы собирались вообще с этим XML делать?
На кой черт мне XML самому глазами парсить?
На кой черт мне XML самому глазами парсить?
А ничего, что вы его еще в глаза не видели и не знаете, есть ли там данные для загрузки в базу или нет? Или вы сначала попробуете программу загрузки написать, а уже когда поймете, что там не XML, а бинарник, решите остановится? )))
Хм… я так понял, что речь именно про XML. Ну да ладно.
На самом деле, я просто считаю, что способность открывать текстовым редактором файлы по 100 мегабайт — вещь во-первых редко используемая в реальной жизни, а во-вторых, не входящая в спектр первой необходимости для IDE. С этим, конечно, vim справится лучше (он же писался для терминалов, где пропускная способность канала до сервера была сопоставима со скоростью набора текста). Но при сегодняшних объемах оперативной памяти… В общем, любой простой редактор это может. И многие не тормозят при этом. TextWrangler, например. Ну, сожрет он эти 100 мегов из памяти — ну и черт с ним.
На самом деле, я просто считаю, что способность открывать текстовым редактором файлы по 100 мегабайт — вещь во-первых редко используемая в реальной жизни, а во-вторых, не входящая в спектр первой необходимости для IDE. С этим, конечно, vim справится лучше (он же писался для терминалов, где пропускная способность канала до сервера была сопоставима со скоростью набора текста). Но при сегодняшних объемах оперативной памяти… В общем, любой простой редактор это может. И многие не тормозят при этом. TextWrangler, например. Ну, сожрет он эти 100 мегов из памяти — ну и черт с ним.
отсутствие автоформатирования xml из коробки.
но, по правде признаться, код выше я как раз и выдрал из своего .vimrc, в котором и исправляется этот досадный недостаток =)
но, по правде признаться, код выше я как раз и выдрал из своего .vimrc, в котором и исправляется этот досадный недостаток =)
au FileType xml exe ":silent 1,$!xmllint --format --recover - 2>/dev/null"Для предварительного взгляда на содержимое использую FAR. И вообще использую его как основной файловый менеджер.
Заменить пользователя в схеме огромной БД для разворачивания на локале, например.
ide для кода, а не для жирных файлов данных, внезапно!
Я тут как сторонний наблюдатель, но вроде как речь именно о том, что IDE не для всего хорошо подходит, и на задаче открытия жирных файлов данных лучше ведут себя редакторы.
Вопрос не по теме, но очень любопытно: а что у вас в файле на 6к+ строк? Это же реально много :)
Вопрос не по теме, но очень любопытно: а что у вас в файле на 6к+ строк? Это же реально много :)
Легаси там. Суммарно несколько миллионов строк в проекте, не один десяток файлов в 1к+ строк
В файле с юнит-тестами
clang-format более 10к строк кода (clang/unittests/Format/FormatTest.cpp). Там даже Emacs иногда притормаживает :)
Редакторы для открытия файлов данных? Обычно такие файлы открываются для изучения, а не изменения (а за изменения в авто-генерируемых файлах надо давать по рукам!) — там простого просмотровщика хватит.
Мне тут на прошлой неделе прислали SQL дамп с лишними символами вначале файла, мол, ты ж инженер, сам разберёшься.
В любом случае, если есть инструмент, не вижу смысла его не использовать.
В любом случае, если есть инструмент, не вижу смысла его не использовать.
Редакторы любят загружать значительный кусок/весь файл в память, всяческие вьюеры стараются не кэшировать такие размеры, а читать по мере надобности…
Так какое решение для ситуации с побитым SQL дампом вы предлагаете?
Это печально, когда складывается ситуация, когда _надо_ подредактировать генерируемый файл данных. Вообще это ставит под сомнение валидность данных вообще (а не только в начале файла).
Поэтому я стараюсь таких ситуаций избегать… Если всё-же приходится — беру простейший, без обвеса редактор и им правлю — такие редакторы не стараются закешировать всё что надо и что не надо.
Поэтому я стараюсь таких ситуаций избегать… Если всё-же приходится — беру простейший, без обвеса редактор и им правлю — такие редакторы не стараются закешировать всё что надо и что не надо.
Когда-то давным-давно была написана утилитка, которая при помощи простых инструкций могла собирать файл из разных кусочков. Как раз для таких случаев, когда во время дискет была необходимость править 1-2 байта в файлах по 100Мб которые тогда не открывались ни в одном редакторе.
Думаю такую программу можно набросать на любом языке под конкретную однократную задачу.
Думаю такую программу можно набросать на любом языке под конкретную однократную задачу.
Откройте исходный код какого-нибудь парсера. Или какой-нибудь контроллер серьезного серверного приложения. Мало ли…
И ИДЕ значительно чаще дает этот выигрышь по времени.
Вот из этого утверждения у вас и складывается позиция, а оно далеко не всегда верно. Я не буду спорить или что-то вам доказывать, но приведу пример, когда «редактор» значительно выигрывает у IDE.
Один из основных языков программирования для меня — это Python. 85% времени при разработке на Python я провожу в режиме «написать функцию -> проверить в REPL». Т.е. подавляющее большинство операций, которые я выполняю, напрямую связаны с переключением между текстовым редактором и REPL.
В Emacs у меня обычно открыто 2 буффера — один для кода, а второй с REPL. Если мне нужно послать отдельное определение или выполнить строчку кода из редактора, я могу сделать это через `C-d` (если вы не знакомы с Emacs, `C` значит «Control», `d` — буква `d`, а `C-d` — сочетание «Control + D»). Если загрузить сразу весь файл — через `C-c C-c`. Если мне нужно ввести какой-то кастомный код, я могу через `C-x b Return` переключиться в соседний буфер и сделать то, что мне нужно.
Я работал с PyCharm — насколько мне известно, одной из наиболее популярных IDE для Python — всего 2 или 3 раза, но так и не понял, как мне получить такой же экпириенс. Документация говорит, что для того, чтобы послать кусок кода в REPL, его нужно сначала выделить, затем в контекстном меню выбрать «Execute selection in console» и нажать «Enter». По моим скромным замерам эта процедура занимает 2.5-3 секунды. В Emacs я за это время успеваю пройтись по функции из 5-8 строк и увидеть результат всех выражений.
Я не знаю, насколько распространён такой подход (да и мне, по большому счёту, всё равно), но для меня «редактор» даёт существенный прирост скорости разработки, а никак не её уменьшение.
Документация говорит, что достаточно выделить и нажать ALT+SHIFT+E.
В другом месте документации правдо сказано, что нажимать надо ALT+SHIFT+I.
Но так или иначе для этого есть сочетание кнопок.
В другом месте документации правдо сказано, что нажимать надо ALT+SHIFT+I.
Но так или иначе для этого есть сочетание кнопок.
Для того, чтобы отправить выделенное — да, наверняка. А чтобы отправить текущую строку? А текущее определение? А если кроме Python вы иногда пишете на Ruby, Clojure или Julia? Я могу вам привести две страницы примеров, когда Emacs значительно ускоряет разработку по сравнению с традиционными IDE. IDE заточены под определённый, достаточно узкий круг задач и возможностей. Редакторы более широкого профиля (а это, кроме Vim и Emacs, также Sublime Text, Atom, LightTable и другие) предоставляют из коробки только основные фичи, но практически неограниченные возможности через расширения. Говорить, что одно в принципе лучше, чем другое — это как-то странно.
Выделяете кусок кода (удобнее всего с помощью Ctrl+W инкрементально выделять), затем Alt+Shift+E и код будет исполнен. И в PyCharm (как и любой другой IDE на основе IDEA) можно практически на любое действие навесить хоткей.
А создать действие «выделить текущую строку и отправить её в REPL» можно?
Можно макрос записать и забиндить его на кнопку.
Может быть я не слишком изощрён в записывании макросов в IDEA, но простой макрос «перейти в конец строки, выделить всё до начала строки, нажать Alt+Shift+E» у меня получился довольно кривой: первые пару строк посылает нормально, потом сбивается. Почему сбивается — непонятно, ибо всё, что у меня есть — визуальное отображение действий, что там происходит внутри я не знаю.
Так или иначе, я могу очень просто усложнить задачу. Как я уже говорил выше, достаточно попробовать отправить в REPL всё выражение (например, функцию). Или открыть в бразере страницу из документации по текущей функции. Или автоматически найти и перейти в корень проекта. Или переключаться по одной горячей клавише между редактором и REPL-ом. Или сделать что угодно из этого удалённо по SSH.
Именно такие кастомизации делают программируемые редакторы такими крутыми, и позволяя автоматизировать любые рутинные действия, какими бы сложными они ни были.
Так или иначе, я могу очень просто усложнить задачу. Как я уже говорил выше, достаточно попробовать отправить в REPL всё выражение (например, функцию). Или открыть в бразере страницу из документации по текущей функции. Или автоматически найти и перейти в корень проекта. Или переключаться по одной горячей клавише между редактором и REPL-ом. Или сделать что угодно из этого удалённо по SSH.
Именно такие кастомизации делают программируемые редакторы такими крутыми, и позволяя автоматизировать любые рутинные действия, какими бы сложными они ни были.
Я вам сейчас целый мир открою:
www.jetbrains.org/intellij/sdk/docs
С помощью вот этого великого знания вы можете добавить к IDEA абсолютно любую фичу. Вот прям совсем-совсем. Вплоть до поддержки нового языка, компилятор ккоторому накодили под пивко на выходных. А уж взять код имеющегося плагина (если он open-source) и добавить в него простую фичу — это вообще час-два работы.
www.jetbrains.org/intellij/sdk/docs
С помощью вот этого великого знания вы можете добавить к IDEA абсолютно любую фичу. Вот прям совсем-совсем. Вплоть до поддержки нового языка, компилятор ккоторому накодили под пивко на выходных. А уж взять код имеющегося плагина (если он open-source) и добавить в него простую фичу — это вообще час-два работы.
А уж взять код имеющегося плагина (если он open-source) и добавить в него простую фичу — это вообще час-два работы.
Час-два работы — это круто. Последнюю фичу в Emacs — переключение на консоль и переход в конец буфера — я написал примерно за 10 минут. Вы бы как раз к этому моменту докачали код плагина и открыли проект.
И давайте на чистоту: как много пользователей IDEA пишут для неё плагины? Для пользователей Emacs это обычные и даже немного рутинное дело.
У пользователей IDEA всё из коробки есть. Если нет силько кастомных фич, то или смериться, или писать плагин. Тут идеология совершенно другая: за деньги тебе дают готовый к использованию продукт.
Последнюю фичу в Emacs — переключение на консоль и переход в конец буфера — я написал примерно за 10 минут
Вот тут-то и кроется ключевая разница между вашим подходом и моим. Я оценил время, требуемое на внедрение и тестирование фичи (просто по привычке — я уже лет пять это делаю регулярно), а вы, очевидно, написали, сколько времени будете вводить код плагина.
И, да, вы правы. Пользователи Eclipse в среднем пишут плагины довольно редко — за них это сделали профессиональные писатели Eclipse-плагинов.
а вы, очевидно, написали, сколько времени будете вводить код плагина.
Нет, я написал полное время разработки — от появления необходимости, до готовой к использованию фичи.
На каком это языке?
Emacs Lisp, вестимо.
Вам бы почитать, что из себя представляет init.el, и как его можно использовать для кастомизации редактора.
Вам бы почитать, что из себя представляет init.el, и как его можно использовать для кастомизации редактора.
Я lisp действительно не знаю. Просто интересно было оценить объем требуемого кода. В любом случае смысла большого в этом нет. Просто полюбопытствовал. Я сам 10 минут бы только разбирался в том, как писать эти расширения. Разумеется, пользоваться средой, в которой навык написания расширений входит в базовый набор навыков для ее использования, я бы не стал. Даже Linux на десктопе сейчас уже ушел от подобного уровня недоработанности.
С точки зрения IDEA — это 2 разных действия, одним хоткеем не получится, к сожалению. Но можно, как написали выше, сделать макрос.
В настройках можно сделать хоткей на выделение всей строки: Select Line at Caret.
P.S. Я почти всегда пользуюсь Ctrl+W — это очень удобно.
В настройках можно сделать хоткей на выделение всей строки: Select Line at Caret.
P.S. Я почти всегда пользуюсь Ctrl+W — это очень удобно.
85% времени при разработке на Python я провожу в режиме «написать функцию -> проверить в REPL». Т.е. подавляющее большинство операций, которые я выполняю, напрямую связаны с переключением между текстовым редактором и REPL.
У вас это вместо тестов чтоли? Не могу представить зачем это может быть нужно глядя на ваше «85% времени разработки».
Боюсь, что это тесты очень часто используются только из-за того, что в языке нет REPL. Последний сценарий, который я делал в REPL:
1. Создать объект, открывающий соединение с БД.
2. Вызвать несколько методов.
3. Посмотреть, что изменилось в БД, проверить логику.
4. Загрузить датасет с подозрительными результатами, преобразовывая каждую запись к объекту модели.
5. Найти ошибку.
REPL, правда, Scala-овский, в нём заменять определения на лету достаточно тяжело, поэтому пофиксить ошибку на лету не получилось. Но сценарий явно не подпадает под определение «вместо тестов».
1. Создать объект, открывающий соединение с БД.
2. Вызвать несколько методов.
3. Посмотреть, что изменилось в БД, проверить логику.
4. Загрузить датасет с подозрительными результатами, преобразовывая каждую запись к объекту модели.
5. Найти ошибку.
REPL, правда, Scala-овский, в нём заменять определения на лету достаточно тяжело, поэтому пофиксить ошибку на лету не получилось. Но сценарий явно не подпадает под определение «вместо тестов».
Я искренне не понимаю что вы с этими REPL'ами делаете. Как вы определяете, что остальной код не сломался из-за ваших правок? Тоже REPL руками? Перед каждым коммитом?
Вы путате тёплое с мягким. Если вам нужны регрессионные тесты, вы пишете тесты. Если вам нужна интерактивная разработка, вы используете REPL. Если у вас нет REPL, тогда да, в некоторых сценариях вы можете заменить его REPL-ом и гонять небольшие куски кода прямо из IDE. Но, как я уже показал выше, работает это далеко не всегда.
Не уверен что с чем я путаю, но ваш подход очень напоминает подход начинающих — когда пишется маленькая демо-программка, которая воспроизводит интересующий сценарий, а после этого благополучно удаляется. Разница между такой программкой и тестом только в том, что тест в итоге остаётся.
Ок, пример с БД, где мне нужно интерактивно исследовать поведение системы, вас не впечатлил. Попробуем по-другому.
Прямо сейчас у меня открыт код классификатора изображений. Суть моей работы состоит в исследовании, какие преобразования над изображением и какие параметры классификатора дают оптимальный результат. В начале работы я загружаю весь набор изображений в память, что занимает примерно 2 минуты. Затем я беру какое-нибудь изображение и начинаю применять к нему фильтры, пытаясь определить, какой из них даст нужные мне признаки. При этом каждый раз я вызываю в REPL функцию применения фильтра и отображения результата на экран.
После того, как я подобрал фильтр-кандидат, я обучаю и кросс-валидирую классификатор-кандидат, что занимает около 1.5 минут. В зависимости от результатов классификатора, я принимаю решение, заменить ли классификатор, заменить ли фильтр, заменить ли их параметры и если да, то на какие.
Каждый следущий шаг зависит от результатов предыдущего. И каждый шаг занимает определенное количество времени, поэтому перезапускать всё сначала и терять, например, уже обученный классификатор — неприемлимая потеря времени. REPL позволяет поддерживать такую разработку. Скажите, как юнит-тесты помогут мне в этой задаче?
Прямо сейчас у меня открыт код классификатора изображений. Суть моей работы состоит в исследовании, какие преобразования над изображением и какие параметры классификатора дают оптимальный результат. В начале работы я загружаю весь набор изображений в память, что занимает примерно 2 минуты. Затем я беру какое-нибудь изображение и начинаю применять к нему фильтры, пытаясь определить, какой из них даст нужные мне признаки. При этом каждый раз я вызываю в REPL функцию применения фильтра и отображения результата на экран.
После того, как я подобрал фильтр-кандидат, я обучаю и кросс-валидирую классификатор-кандидат, что занимает около 1.5 минут. В зависимости от результатов классификатора, я принимаю решение, заменить ли классификатор, заменить ли фильтр, заменить ли их параметры и если да, то на какие.
Каждый следущий шаг зависит от результатов предыдущего. И каждый шаг занимает определенное количество времени, поэтому перезапускать всё сначала и терять, например, уже обученный классификатор — неприемлимая потеря времени. REPL позволяет поддерживать такую разработку. Скажите, как юнит-тесты помогут мне в этой задаче?
как юнит-тесты помогут мне в этой задаче?
Никак. Вы прыгнули с задачи про «соединение с БД и поиск ошибки» на задачу а-ля матлаб.
Давайте теперь предположим, что вы дошли до 10-го шага, когда должны получиться там какие-то финальные результаты, но получается полная хрень. И тут вы осознаёте, что ошибка была где-то на шаге 3. Будь это отдельный скрипт — открыли, поправили, запустили и пошли пить кофе. В вашем же случае нужно участие человека.
А теперь давайте предположим, что к вам в команду пришёл новый сотрудник Вася и просит поделиться с ним вашими наработками. Вы ему дамп процесса python снимете и попросите восстановить на его машине? Попутно рассказывая, что первый шаг это 8 раз вверх, второй — 6, а если 4 вверх, то там ошибка, и результаты никуда не пошли?
Никак. Вы прыгнули с задачи про «соединение с БД и поиск ошибки» на задачу а-ля матлаб.
Задача про БД ничем принципиально не отличается от задачи «а-ля матлаб» — и там, и там у вас есть данные и/или функции, которые нужно исследовать и в зависимости от результата решить, что делать дальше. Я вам могу ещё с десяток таких же примеров привести, начиная от работы со сторонними API и заканчивая зажиганием лампочек на Raspberry Pi, где интерактивная консоль экономит уйму времени при разработке. «При разработке» здесь ключевое слово.
Давайте теперь предположим, что вы дошли до 10-го шага, когда должны получиться там какие-то финальные результаты, но получается полная хрень. И тут вы осознаёте, что ошибка была где-то на шаге 3. Будь это отдельный скрипт — открыли, поправили, запустили и пошли пить кофе. В вашем же случае нужно участие человека.
А кто вам запрещает иметь рядом скрипт? Собственно, я ещё в самом первом комментарии написал:
В Emacs у меня обычно открыто 2 буффера — один для кода, а второй с REPL.
Вы пишете программу как обычно, оформляете в такие же функции и модули, пользуетесь подсветкой синтаксиса и автодополнением, только плюс к этому у вас ещё есть интерактивная консоль, где любую функцию можно попробовать напрямую.
А теперь давайте предположим, что к вам в команду пришёл новый сотрудник Вася и просит поделиться с ним вашими наработками. Вы ему дамп процесса python снимете и попросите восстановить на его машине? Попутно рассказывая, что первый шаг это 8 раз вверх, второй — 6, а если 4 вверх, то там ошибка, и результаты никуда не пошли?
Аналогично, Вася получит кодовую базу, ничем не отличающуюся от той, что кто-нибудь мог бы сделать в PyCharm и/или без REPL.
заменить его REPL-ом
Заменить его unit-тестами, конечно же.
Боюсь, что это тесты очень часто используются только из-за того, что в языке нет REPL. Последний сценарий, который я делал в REPL
Боюсь, что подобные утверждения понижают мнение сообщества об уровне вашей квалификации. Очевидным (и основным) преимуществом Unit-тестирования является его автоматизм. То есть вы прогоняете Unit-тесты КАЖДЫЙ РАЗ, когда меняете что-то. Руками при этом ничего делать не нужно. И не должно быть нужно. Потому что руками вы можете не сделать, забыть, ошибиться… А компилятор не забудет и не пропустит тест (если, конечно, нерадивый разработчик сам его не отключит).
Общее правило таково: если процесс разработки на 80% состоит из <какое-то простое действие>, значит вы что-то делаете не так.
Спасибо за увлекательную лекцию про unit-тесты, а теперь покажите мне, где я утверждал, что они не нужны? Если вы дочитаете вот этот самый комментарий до конца, то, наверное, заметите, что его основной объект — REPL, и то, какие задачи с его помощью можно решать, в частности, интерактивная разработка и возможность видеть результаты каждого вызова (например, к стороннему API, который вы досконально ещё не знаете).
В языках без REPL, таких как Java, аналогичные задачи приходится решать через подручные средства, например добавлением временного метода `main` или метода с аннотацией JUnit, который можно запустить тут же правой кнопкой мыши. Это криво, неудобно и занимает гораздо больше времени, но из доступных решений оно — самое простое.
Каким образом фраза «тесты очень часто используются только из-за того, что в языке нет REPL» превратилась в головах некоторых читающих в «тесты не нужны, REPL их полностью заменяет» для меня непонятно. Ну ладно, будем считать, что это мой косяк и неудачно построенная фраза. Но после этой фразы идёт ещё с десяток моих комментариев (например, непосредственно следущий за тем, что вы процетировали), где я поясняю свою мысль, развеивая идею, что я каким-то образом почему-то против тестов. Но нет, вы, почему-то, предпочли пропустить всё это, и на основе одной неправильно понятой вами фразы сделать выводы о моей квалификации. Ура, товарищи, отличный вывод!
В языках без REPL, таких как Java, аналогичные задачи приходится решать через подручные средства, например добавлением временного метода `main` или метода с аннотацией JUnit, который можно запустить тут же правой кнопкой мыши. Это криво, неудобно и занимает гораздо больше времени, но из доступных решений оно — самое простое.
Каким образом фраза «тесты очень часто используются только из-за того, что в языке нет REPL» превратилась в головах некоторых читающих в «тесты не нужны, REPL их полностью заменяет» для меня непонятно. Ну ладно, будем считать, что это мой косяк и неудачно построенная фраза. Но после этой фразы идёт ещё с десяток моих комментариев (например, непосредственно следущий за тем, что вы процетировали), где я поясняю свою мысль, развеивая идею, что я каким-то образом почему-то против тестов. Но нет, вы, почему-то, предпочли пропустить всё это, и на основе одной неправильно понятой вами фразы сделать выводы о моей квалификации. Ура, товарищи, отличный вывод!
В языках «таких как Java» не требуется добавлять временный метод main, так как достаточно проставить точку останова в нужное место и после этого ввести в Watch нужное вам выражение.
Я ничего не пропускал, я ответил на вот это заявление:
Я никаких выводов не делал. Всего лишь указал вам на то, что считаю неверным и предупредил, что вас могут понять превратно.
Я ничего не пропускал, я ответил на вот это заявление:
85% времени при разработке на Python я провожу в режиме «написать функцию -> проверить в REPL». Т.е. подавляющее большинство операций, которые я выполняю, напрямую связаны с переключением между текстовым редактором и REPL.
Я никаких выводов не делал. Всего лишь указал вам на то, что считаю неверным и предупредил, что вас могут понять превратно.
В языках «таких как Java» не требуется добавлять временный метод main, так как достаточно проставить точку останова в нужное место и после этого ввести в Watch нужное вам выражение.
А теперь давайте поиском по странице найдём мой комментарий со словом «watch», в котором я подробно рассказываю, почему дебаггер + watch даже рядом не стоят с REPL.
Я никаких выводов не делал. Всего лишь указал вам на то, что считаю неверным и предупредил, что вас могут понять превратно.
Интересный у вас способ отреагировать на это заявление, если процитировали вы совершенно другое. Ну ладно, пусть будет по-вашему. Может быть у вас есть какие-то аргументы, почему вы считаете, что я на своём языке программирования делаю свои же задачи неправильно? Расскажите мне, пожалуйста, как мне правильно программировать на Python и самое главное почему?
Расскажите мне, пожалуйста, как мне правильно программировать на Python и самое главное почему?
Надеюсь, мое мнение вас не оскорбит. Но мне python не нравится совсем. И я вообще предпочитаю на нем не программировать. Это — уже совсем другой спор…
Вы радуетесь в своем любимом языке вещам, которые меня в нем раздражают. А я, например, очень радуюсь, что в Java есть checked exceptions, которые вызывают недоумение у python-разработчиков (и не только у них). Это — тоже своего рода религия.
Мой лучший друг — питонщик. Мы никогда не сможем в этом друг друга понять. Мировая наша с ним состоит в том, что питон удобен для маленьких программ, а Java — для больших. Это — единственный консенсус в области идеологии, которого мы смогли достигнуть.
Боюсь, что это тесты очень часто используются только из-за того, что в языке нет REPL.
Я вам процитировал эту фразу, потому что предыдущую вам процитировали выше. А так как я комментарии читал сверху вниз и отвечал последовательно, то, что вы писали ниже, я прочел позже.
Надеюсь, мое мнение вас не оскорбит. Но мне python не нравится совсем. И я вообще предпочитаю на нем не программировать. Это — уже совсем другой спор…
Вот в следущий раз лучше сразу начинайте комментарий со слов «по-моему мнению», это снимет много вопросов.
Мировая наша с ним состоит в том, что питон удобен для маленьких программ, а Java — для больших.
Охх, как же уже надоели эти мифы...
А так как я комментарии читал сверху вниз и отвечал последовательно, то, что вы писали ниже, я прочел позже.
Т.е. вы сначала прочитали первое предложение, потом ответили, а потом дочитали комментарий? Окааай.
А наличие крупных проектов на языке что-то говорит об удобстве написания оных на нём? Код ядра линукс тоже долгое время был на чистых сях, потом переехал на плюсы, если мне память не изменяет.
Код ядра линукс тоже долгое время был на чистых сях, потом переехал на плюсы, если мне память не изменяет.
Ага, аж на 0.6%.
Код ядра линукс тоже долгое время был на чистых сях, потом переехал на плюсы, если мне память не изменяет.
Память вам изменяет. Линус ни за что не пустит плюсы в ядро.
Возможно, вы имели в виду GCC.
YouTube — жуткая дрянь в плане надежности. Не думаю, что дело в том, на чем он написан. Но факт остается фактом. То стриминг глючит, то еще что-то…
Но комментатор ниже прав: наличие крупных проектов само по себе не доказывает, что язык для них пригоден. Вот, Facebook и Wikipedia вообще, прости господи, на PHP написаны. А работают. Но сколько же туда усилий и пота кровавого вложено…
Но комментатор ниже прав: наличие крупных проектов само по себе не доказывает, что язык для них пригоден. Вот, Facebook и Wikipedia вообще, прости господи, на PHP написаны. А работают. Но сколько же туда усилий и пота кровавого вложено…
Естественно, все ж дураки, один вы знаете, как крупные проекты нужно писать.
Зато мы теперь знаем как их НЕ НУЖНО писать.
Крупные проекты это такая штука… никогда нельзя сказать насколько сложными они окажутся через пару лет используя конкретные технологии. А при неудачном выборе, попытка переписать на более подходящих технологиях аналогична разработке с нуля со всеми вытекающими.
Крупные проекты это такая штука… никогда нельзя сказать насколько сложными они окажутся через пару лет используя конкретные технологии. А при неудачном выборе, попытка переписать на более подходящих технологиях аналогична разработке с нуля со всеми вытекающими.
Проблема роста проекта успешно решается через модульность уже много лет. Причём модульность в любом виде, так что даже проекты на C, в котором на уровне языка такого понятия нет, прекрасно растут просто за счёт правильной организации кода и инклюдов. Единственная проблема масштабируемости, которая зависит от языка и технологии, это проблема роста производительности. Но к организации кода она не имеет никакого отношения.
Причем тут я? Я участвовал в крупных проектах, которые писались хорошо. И участвовал в тех, которые писались плохо. И в том, и в другом случае я старался сделать лучше. Однажды мое нежелание делать дрянной код двигаясь на поводу у людей, не желающих думать в процессе разработки привело к тому, что я просто ушел из проекта. Потому что на мои попытки улучшить архитектуру архитекторы отвечали мне: «идея твоя хороша и верна, но мы ее не будем внедрять, так как в команде есть люди, которые ее не поймут». При этом и они, и я хорошо понимали, о ком именно идет речь.
О чем это я? О том, что 1000 обезьян может быть и не напишут «Войну и Мир» за год, стуча по машинкам, но зато они обойдутся фирме намного дешевле, чем 2-3 писателя. А разницы в готовом продукте всё равно никто не заметит, пока этот продукт — лидер и почти монополист. «Nothing personal, just business»
О чем это я? О том, что 1000 обезьян может быть и не напишут «Войну и Мир» за год, стуча по машинкам, но зато они обойдутся фирме намного дешевле, чем 2-3 писателя. А разницы в готовом продукте всё равно никто не заметит, пока этот продукт — лидер и почти монополист. «Nothing personal, just business»
Не понял, какое отношение ваш комментарий имеет к вопросу удобства написания крупных проектов на разных языках?
Вы меня обвинили в самоуверенности на основании моих чисто пользовательских наблюдений за YouTube. Я решил ответить на это заявление.
Встречный вопрос: какое отношение имеет к качеству YouTube-а мое умение или неумение делать крупные проекты правильно? Я лишь указал, что приводить его в качестве примера удачи — неверно.
Встречный вопрос: какое отношение имеет к качеству YouTube-а мое умение или неумение делать крупные проекты правильно? Я лишь указал, что приводить его в качестве примера удачи — неверно.
Вы меня обвинили в самоуверенности на основании моих чисто пользовательских наблюдений за YouTube.
Я вам про YouTube вообще ничего не говорил, это вы почему-то выбрали из списка крупных проектов на Python тот, с которым у вас не сложилось, и на этом примере стали рассказывать про то, что одни языки предназначены для крупных проектов, а другие нет.
А ответил я вам на вот это:
Но комментатор ниже прав: наличие крупных проектов само по себе не доказывает, что язык для них пригоден.
Думаю, скорее, вместо «постоянной пересборки проекта в фоновом режиме» при написании программ на Java в IDE типа Eclipse. То же самое, только руками. И в эти «85% времени разработки» входит не только проверка в REPL, но и собственно написание функции.
Думаю, скорее, вместо «постоянной пересборки проекта в фоновом режиме» при написании программ на Java в IDE типа Eclipse.
Близко, но не совсем. Я бы скорее сравнил с написанием bash-скриптов: прежде, чем написать весь скрипт, вы выполняете команды в консоли. Написали, всё хорошо — добавили в файл, что-то сделали не так — исправили и после проверки и добавили в файл. Т.е. вместо того, чтобы сначала написать всю программу (с main-ом и всем таким) и потом проверять сразу всё, вы запускаете каждую функцию сразу после написания и проверяете, что получилось именно то, что ожидали. Ну и потом опционально ещё запихиваете тот же самый код из REPL в тесты.
Когда такая «REPL-ориентированная» разработка бывает полезна? Мне она помогает как минимум в таких ситуациях:
1. При работе со внешними ресурсами, например, базой данных или API. Скажем, нашли вы библиотеку для работы с Facebook API, как проверить, что она вообще работает? Правильно, сделать несколько вызовов. В Java и других языках без REPL мне бы пришлось писать маленькую программу или unit-тест (ненастоящий, просто какой-то кусок кода, который можно запустить и посмотреть результат). В языках с поддержкой REPL я могу сделать эти вызовы напрямую и, если всё хорошо, пойти дальше.
2. В качестве расширенного автокомплита / анализатора кода. Я думаю, все согласятся, что автокомплит — это круто. Но автокомплит позволяет только найти подходящую функцию по имени и/или аргументам. В то же время REPL позволяет непосредственно запустить функцию, и проверить не только её корректность не только с точки зрения семантики языка, но и с собственно данных, которые она обрабатывает.
3. Вместо/в дополнение к дебаггеру. Дебаггер позволяет внедриться в программу, и проверить по шагам, как она выполняется. Это круто, правда. В то же время, дебаггер не может сделать step back, выполнить кастомную команду (в некоторых случаях работает watch expression, но не всегда), заменить значение переменной и т.д. REPL позволяет эмулировать работающую программу, и при этом изменять любые детали, вплоть до кода используемых функций.
4. Возможность удерживать состояние. В общем-то, это напрямую выплывает из предыдущего пунтка. Иногда мы хотим иметь возможность сохранять значение переменной в памяти между запросами, например, при ограничении количества запросов к API, или просто после долгих вычислений. И REPL позволяет очень тонко управлять этим процессов, сохраняя состояние как угодно долго.
В общем-то, вариантов использования очень много, поэтому мне и было странно услышать про сравнение с unit-тестами :)
Из ваших слов создается впечатление, что главная проблема IDE для питона состоит в том, что ее нет… Вернее, в том, что она ужасно недоработана.
Позвольте, я вам «притчу» расскажу.
Есть такая компания — IBM. Гигантская, к слову, компания — что только ни производит, чем только ни занимается. И вот занялась она Джавой. Всерьез занялась, поскольку язык этот ей показался очень перспективным. Шел конец 90-х, Java-апплеты еще встречались на сайтах, а Java Enterprise еще только начинался и едва конкурировал с Perl-ом в папочке cgi-bin.
А IBM со свойственным им размахом начали чудовищного размера проект, писать который предстояло долго и упорно. Ну то есть сейчас он уже чудовищного размера. А тогда, ясное дело, только начинался.
И так как вложено в проект было очень много, им необходима была реально крутая отдача от разработчиков. И какой-то мудрый человек (увы, не знаю, как его звали) решил в 2001 году вложиться в создание крутой профессиональной Java IDE. Учитывая их бюджет, расходы на написание IDE были сущей мелочью — и они ее написали. Тяжелую и профессиональную, с высоким порогом вхождения и всеми необходимыми фичами. Написали не «за бабки», а «для себя» — и много лет вылизывали и тестировали этот JDT, будь он неладен. Сейчас он сияет и переливается. Уже года два не видел, чтобы eclipse в чистом java-проекте падал, если не прицеплять всякие левые JBoss-поделки. Завидная стабильность по сегодняшним временам!
И именно благодаря этому у джавистов сегодня есть эта замечательная штука — Eclipse. И, как мне кажется, это является главным критерием «зрелости» языка — если огромная компания готова создать мощную IDE для этого языка даже не на коммерческой основе, а так, как поделку, как побочный продукт своей технологии.
Надеюсь, что кто-нибудь и за python возьмется. И будет следующее (или даже это) поколение питонщиков с удивлением тут писать: как вообще можно код править в vim? Есть же «Pyclipse»!
Позвольте, я вам «притчу» расскажу.
Есть такая компания — IBM. Гигантская, к слову, компания — что только ни производит, чем только ни занимается. И вот занялась она Джавой. Всерьез занялась, поскольку язык этот ей показался очень перспективным. Шел конец 90-х, Java-апплеты еще встречались на сайтах, а Java Enterprise еще только начинался и едва конкурировал с Perl-ом в папочке cgi-bin.
А IBM со свойственным им размахом начали чудовищного размера проект, писать который предстояло долго и упорно. Ну то есть сейчас он уже чудовищного размера. А тогда, ясное дело, только начинался.
И так как вложено в проект было очень много, им необходима была реально крутая отдача от разработчиков. И какой-то мудрый человек (увы, не знаю, как его звали) решил в 2001 году вложиться в создание крутой профессиональной Java IDE. Учитывая их бюджет, расходы на написание IDE были сущей мелочью — и они ее написали. Тяжелую и профессиональную, с высоким порогом вхождения и всеми необходимыми фичами. Написали не «за бабки», а «для себя» — и много лет вылизывали и тестировали этот JDT, будь он неладен. Сейчас он сияет и переливается. Уже года два не видел, чтобы eclipse в чистом java-проекте падал, если не прицеплять всякие левые JBoss-поделки. Завидная стабильность по сегодняшним временам!
И именно благодаря этому у джавистов сегодня есть эта замечательная штука — Eclipse. И, как мне кажется, это является главным критерием «зрелости» языка — если огромная компания готова создать мощную IDE для этого языка даже не на коммерческой основе, а так, как поделку, как побочный продукт своей технологии.
Надеюсь, что кто-нибудь и за python возьмется. И будет следующее (или даже это) поколение питонщиков с удивлением тут писать: как вообще можно код править в vim? Есть же «Pyclipse»!
А хотите, я вам расскажу альтернативную притчу? C 91 по 95 год человек по имени Джейсм Гослинг работал над языком Oak в компании Sun Microsystems. Sun Microsystems на тот момент, вообще говоря, была не столько софтварной, сколько хардварной компанией, производящей большое разнообразие серверов, десктопных и микрокомпьютеров. Естественным желанием компании было найти общий знаменатель для всех своих систем. Отсюда и появился Java bytecode, а также знаменитый лозунг «write once, run anywhere».
В начале 2000х случился бум доткомов, тотальное распространение интернета и клиент-серверного ПО. Если есть потребность в программах, есть и потребность в разработчиках, способных их создавать. Проблема в том, что в тот момент достаточно квалифицированных разработчиков, способных писать на менстримовом C++ серверное ПО, которое бы не «текло» и не приводило к segfault-ам, было гораздо меньше, чем требовалось. Процесс обучения новых рекрутов был длительным и болезненным, поэтому нужно было снижать планку.
И вот тут Java выстрелила. В ней не нужно было следить за выделением и освобождением памяти, не нужно было учить 100500 замысловатых конструкций и концепций языка и даже исключения везде указывались явно, так что забыть их проверить было просто невозможно. Просто идеальный язык для толпы низкоквалифицированных недоспециалистов.
Но одной только смены языка недостаточно, чтобы успешно (с точки зрения дальнейшей продажи) писать большие проекты. Всё-таки нужны были тим лиды, простые правила, показывающие, как «правильно», и постоянный рефакторинг. Вручную перерефакторить говнокод, написанный толпой обезъянок, — та ещё работёнка. Поэтому нужны были средства для упрощения поиска нужных классов (из структуры директорий то непонятно, где что лежит), массового переименования (сразу то подумать как назвать переменную нельзя), вынесения методов в общий абстрактный класс (ведь простые правила, которые показал тимлид, в данном случае оказались слишком упрощёнными).
А как автоматизировать все эти задачи? Правильно, написать IDE, которая не заставит недоспециалистов писать хороший код, но позволит потом проще разгребать получившуюся кашу. И именно поэтому, как уже неоднократно замечали тут в комментариях, Java — это практически единственный язык, писать на котором без IDE просто невозможно.
Вся эта история, конечно, ложь и профанация — я за спиной у Гослинга и IBM не стоял, и как всё было на самом деле знать не могу. Но скажите, чем ваша история лучше?
В начале 2000х случился бум доткомов, тотальное распространение интернета и клиент-серверного ПО. Если есть потребность в программах, есть и потребность в разработчиках, способных их создавать. Проблема в том, что в тот момент достаточно квалифицированных разработчиков, способных писать на менстримовом C++ серверное ПО, которое бы не «текло» и не приводило к segfault-ам, было гораздо меньше, чем требовалось. Процесс обучения новых рекрутов был длительным и болезненным, поэтому нужно было снижать планку.
И вот тут Java выстрелила. В ней не нужно было следить за выделением и освобождением памяти, не нужно было учить 100500 замысловатых конструкций и концепций языка и даже исключения везде указывались явно, так что забыть их проверить было просто невозможно. Просто идеальный язык для толпы низкоквалифицированных недоспециалистов.
Но одной только смены языка недостаточно, чтобы успешно (с точки зрения дальнейшей продажи) писать большие проекты. Всё-таки нужны были тим лиды, простые правила, показывающие, как «правильно», и постоянный рефакторинг. Вручную перерефакторить говнокод, написанный толпой обезъянок, — та ещё работёнка. Поэтому нужны были средства для упрощения поиска нужных классов (из структуры директорий то непонятно, где что лежит), массового переименования (сразу то подумать как назвать переменную нельзя), вынесения методов в общий абстрактный класс (ведь простые правила, которые показал тимлид, в данном случае оказались слишком упрощёнными).
А как автоматизировать все эти задачи? Правильно, написать IDE, которая не заставит недоспециалистов писать хороший код, но позволит потом проще разгребать получившуюся кашу. И именно поэтому, как уже неоднократно замечали тут в комментариях, Java — это практически единственный язык, писать на котором без IDE просто невозможно.
Вся эта история, конечно, ложь и профанация — я за спиной у Гослинга и IBM не стоял, и как всё было на самом деле знать не могу. Но скажите, чем ваша история лучше?
Кхм… т.е. на плюсах пишут только труъ-профи? ;)
«Поэтому нужны были средства для упрощения поиска нужных классов (из структуры директорий то непонятно, где что лежит)» — невозможно создать абсолютно продуманную структуру директорий + неймспейсы бывают очень полезны (но накладывают ограничение на модель хранения — ту самую структуру директорий). А если подключить ещё пару фреймворков и вспомнить огромное JDK — то даже на простом проекте без поиска приходится тяжеловато (все классы не запомнишь).
«массового переименования (сразу то подумать как назвать переменную нельзя)» — можно, но в процессе написания кода, бывает, приходит понимание более точного названия — вручную переименовывать?
«вынесения методов в общий абстрактный класс (ведь простые правила, которые показал тимлид, в данном случае оказались слишком упрощёнными)» — опять же в процессе разработки класс разрастается + появляются классы с похожим функционалом — вынести общее в общий абстрактный — вполне себе вариант. Или вы пишите только по заранее утверждённому ТЗ и в дальнейшем никогда не меняете код?
И да, вы ещё забыли кучу различных рефакторингов «вынести в метод», «вынести в переменную», «вынести в константу», «использовать интерфейс, где возможно» и прочие-прочие… Как вы смогли упустить такой пласт для отзывов об «обезъянках»?
«Поэтому нужны были средства для упрощения поиска нужных классов (из структуры директорий то непонятно, где что лежит)» — невозможно создать абсолютно продуманную структуру директорий + неймспейсы бывают очень полезны (но накладывают ограничение на модель хранения — ту самую структуру директорий). А если подключить ещё пару фреймворков и вспомнить огромное JDK — то даже на простом проекте без поиска приходится тяжеловато (все классы не запомнишь).
«массового переименования (сразу то подумать как назвать переменную нельзя)» — можно, но в процессе написания кода, бывает, приходит понимание более точного названия — вручную переименовывать?
«вынесения методов в общий абстрактный класс (ведь простые правила, которые показал тимлид, в данном случае оказались слишком упрощёнными)» — опять же в процессе разработки класс разрастается + появляются классы с похожим функционалом — вынести общее в общий абстрактный — вполне себе вариант. Или вы пишите только по заранее утверждённому ТЗ и в дальнейшем никогда не меняете код?
И да, вы ещё забыли кучу различных рефакторингов «вынести в метод», «вынести в переменную», «вынести в константу», «использовать интерфейс, где возможно» и прочие-прочие… Как вы смогли упустить такой пласт для отзывов об «обезъянках»?
Кхм… т.е. на плюсах пишут только труъ-профи? ;)
Это значит, что на подготовку более или менее самостоятельного C++ разработчика уходит чертовски много времени.
А если подключить ещё пару фреймворков и вспомнить огромное JDK — то даже на простом проекте без поиска приходится тяжеловато (все классы не запомнишь).
Apache Spark — прекрасный пример, где структура директорий практически однозначно определяет местоположение какого-то куска кода. По сути, если пропустить общий для всех пакетов префикс «org.apache.spark», то получается практически двухуровневая иерархия — имя подпакета (например, «rdd», «storage», «scheduler») и дальше список файлов-классов.
можно, но в процессе написания кода, бывает, приходит понимание более точного названия — вручную переименовывать?
Внешний API модуля меняется редко, так что на практике даже ручное переименование не создаёт особых проблем. Т.е. фича полезная, но не критичная.
опять же в процессе разработки класс разрастается + появляются классы с похожим функционалом — вынести общее в общий абстрактный — вполне себе вариант.
Ctrl+X Ctrl+V раз в месяц — не проблема, проблема именно когда рефакторинг становится ежедневным и/или длительным процессом.
И да, вы ещё забыли кучу различных рефакторингов
Я ничего не забыл, но ведь и вы помните, что всё это спекуляция, и к реальности может не иметь никакого отношения?
«Внешний API модуля меняется редко, так что на практике даже ручное переименование не создаёт особых проблем. Т.е. фича полезная, но не критичная. „
Когда случается потребность (пусть и редкая) — становится очень даже критичной. Ну и для работы с внутренними переменными тоже бывает полезно
“Ctrl+X Ctrl+V раз в месяц — не проблема, проблема именно когда рефакторинг становится ежедневным и/или длительным процессом.»
Не проблема… но геморрой… Это как вместо cvs использовать бекапы — можно, но неудобно. Инструменты рефакторинга это делать аккуратнее, быстрее и с лучшим охватом мест использования (не приходится их искать).
«Я ничего не забыл, но ведь и вы помните, что всё это спекуляция, и к реальности может не иметь никакого отношения?»
Понимаю, но слишком уж максималитичо было сказано.
Когда случается потребность (пусть и редкая) — становится очень даже критичной. Ну и для работы с внутренними переменными тоже бывает полезно
“Ctrl+X Ctrl+V раз в месяц — не проблема, проблема именно когда рефакторинг становится ежедневным и/или длительным процессом.»
Не проблема… но геморрой… Это как вместо cvs использовать бекапы — можно, но неудобно. Инструменты рефакторинга это делать аккуратнее, быстрее и с лучшим охватом мест использования (не приходится их искать).
«Я ничего не забыл, но ведь и вы помните, что всё это спекуляция, и к реальности может не иметь никакого отношения?»
Понимаю, но слишком уж максималитичо было сказано.
Когда случается потребность (пусть и редкая) — становится очень даже критичной. Ну и для работы с внутренними переменными тоже бывает полезно
Внутренние переменные прекрасно заменяются через string replace, так что это вообще не проблема. Для внешних вполне работает grep и sed. Но если это может делать IDE, то это несомненный плюс, тут не поспоришь. Однако я честно не думаю, что IDE для Java получили такое развитие только из-за необходимости время от времени переименовывать переменные.
Инструменты рефакторинга это делать аккуратнее, быстрее и с лучшим охватом мест использования (не приходится их искать).
Да ладно, что именно во внешних зависимостях поменяется, если вы часть методов вынесите из данного класса в его абстрактного предка?
Понимаю, но слишком уж максималитичо было сказано.
Я это к тому, что никогда нельзя делать однозначные заявления о том, почему и зачем что-то произошло. И никогда не стоит решать за других людей, как им удобней работать и какие инструменты для них важнее.
Ваша история ничем не лучше моей. Но в ней-таки слишком много неоправданной злости. Даже хамства, я бы сказал.
Я сознательно перешел на Java с C++, уже имея весьма солидный опыт написания программ на нем. Потому что я, по вашему определению, «самоосознанная обезьянка».
1. Я считаю, что язык C++ образца 98 года ужасен, потому что не позволяет отделаться от кучи мелких ошибок. Даже опечатки в нем часто приводят к багам, над которыми приходится просидеть неделю. Попробуйте на досуге поиграть в «русскую рулетку» — найдите и удалите в большом проекте случайный символ "&". Язык, в котором подобной дряни не наблюдается, несомненно лучше. И для разработчиков, и для пользователей.
2. Я считаю, что регулярное переосмысление архитектуры проекта и последующий рефакторинг «говнокода» — неизбежная санитарная процедура. И если вы думаете, что лично вы не производите этот «говнокод» в промышленных масштабах, то смею вас заверить. Его производят абсолютно все, вне зависимости от языка и квалификации. С первого раза ни одна система не строится.
И, наконец:
3. Я убежден, что разработка ПО требует мышления в рамках некоторой выбранной парадигмы. И чем строже вы ограничиваете себя этой парадигмой (будь то ООП, ФП или даже АОП), тем качественнее ваш выхлоп. И, да, я предпочитаю, чтобы меня ограничивал компилятор, а системы статического анализа моего кода были встроены в тот текстовый редактор, в котором я этот код набираю и «били меня по башке» всякий раз, когда я пишу дрянь. Спортсмены вполсилы не играют даже с младшей сестренкой во дворе. Это расхолаживает.
Я не знаю, чем на самом деле руководствовались IBM. Но если вашу историю придумали вы, то я вынужден считать, что она больше характеризует вас самого, нежели кого-то другого.
Кстати, прекрасный пассаж:
Во-первых, потрудитесь почитать хоть что-то вот от этого господина, например. Вы поймете хотя бы приблизительно, какого уровня задачи решают «обезьянки» в своей повседневной работе. А если хотите знать, что им приходится учить, то, например, вот.
А во-вторых, посмотрите, как часто в вашем любимом проекте вылетают исключения, которые кто-то по ошибке забыл поймать. И подумайте, наконец, — друг вам тот, кто ваши ошибки помогает вытащить наружу, или враг.
Неверное утверждение. И никто тут этого не писал. Верное утверждение такое:
Java — почти единственный язык, инфраструктура которого развита до такого высокого уровня, что ни один адекватный человек не станет работать отшельником хрен-пойми-в-чем, вместо использования нормального, специально предназначенного для Java инструмента.
Попробуйте — поймете.
Я сознательно перешел на Java с C++, уже имея весьма солидный опыт написания программ на нем. Потому что я, по вашему определению, «самоосознанная обезьянка».
1. Я считаю, что язык C++ образца 98 года ужасен, потому что не позволяет отделаться от кучи мелких ошибок. Даже опечатки в нем часто приводят к багам, над которыми приходится просидеть неделю. Попробуйте на досуге поиграть в «русскую рулетку» — найдите и удалите в большом проекте случайный символ "&". Язык, в котором подобной дряни не наблюдается, несомненно лучше. И для разработчиков, и для пользователей.
2. Я считаю, что регулярное переосмысление архитектуры проекта и последующий рефакторинг «говнокода» — неизбежная санитарная процедура. И если вы думаете, что лично вы не производите этот «говнокод» в промышленных масштабах, то смею вас заверить. Его производят абсолютно все, вне зависимости от языка и квалификации. С первого раза ни одна система не строится.
И, наконец:
3. Я убежден, что разработка ПО требует мышления в рамках некоторой выбранной парадигмы. И чем строже вы ограничиваете себя этой парадигмой (будь то ООП, ФП или даже АОП), тем качественнее ваш выхлоп. И, да, я предпочитаю, чтобы меня ограничивал компилятор, а системы статического анализа моего кода были встроены в тот текстовый редактор, в котором я этот код набираю и «били меня по башке» всякий раз, когда я пишу дрянь. Спортсмены вполсилы не играют даже с младшей сестренкой во дворе. Это расхолаживает.
Я не знаю, чем на самом деле руководствовались IBM. Но если вашу историю придумали вы, то я вынужден считать, что она больше характеризует вас самого, нежели кого-то другого.
Кстати, прекрасный пассаж:
В ней не нужно было следить за выделением и освобождением памяти, не нужно было учить 100500 замысловатых конструкций и концепций языка и даже исключения везде указывались явно, так что забыть их проверить было просто невозможно.
Во-первых, потрудитесь почитать хоть что-то вот от этого господина, например. Вы поймете хотя бы приблизительно, какого уровня задачи решают «обезьянки» в своей повседневной работе. А если хотите знать, что им приходится учить, то, например, вот.
А во-вторых, посмотрите, как часто в вашем любимом проекте вылетают исключения, которые кто-то по ошибке забыл поймать. И подумайте, наконец, — друг вам тот, кто ваши ошибки помогает вытащить наружу, или враг.
Java — это практически единственный язык, писать на котором без IDE просто невозможно.
Неверное утверждение. И никто тут этого не писал. Верное утверждение такое:
Java — почти единственный язык, инфраструктура которого развита до такого высокого уровня, что ни один адекватный человек не станет работать отшельником хрен-пойми-в-чем, вместо использования нормального, специально предназначенного для Java инструмента.
Попробуйте — поймете.
Потому что я, по вашему определению, «самоосознанная обезьянка».
Никаких определений я не давал.
Я считаю, что язык C++ образца 98 года ужасен
Да. И это никак не противоречит тому, что я написал.
Я считаю, что регулярное переосмысление архитектуры проекта и последующий рефакторинг «говнокода» — неизбежная санитарная процедура.
Рефакторинг — да, говнокода — нет. Достаточно освоить всего пару базовых принципов, чтобы свести 85% случаев рефакторинга к изменению внутри одного модуля.
Я убежден [...]
Вы правильно начали фразу, но не забывайте, что не все разделяют ваши убеждения.
Во-первых, потрудитесь почитать хоть что-то вот от этого господина, например. Вы поймете хотя бы приблизительно, какого уровня задачи решают «обезьянки» в своей повседневной работе.
Читал. И какого же уровня эти задачи?
А если хотите знать, что им приходится учить, то, например, вот.
Да, именно про них я и говорил. Это что-то меняет в моей фразе?
А во-вторых, посмотрите, как часто в вашем любимом проекте вылетают исключения, которые кто-то по ошибке забыл поймать.
Те, которое кто-то по ошибке забыл поймать — нечасто. Те, которые должны специально сломать стек и сигнализировать про исключительную ситуацию — чаще, и это хорошо.
Попробуйте — поймете.
Попробовать что? Я 5 лет писал на Java как на основном языке программирования. Работал и с IDEA, и с Eclipse, и с Netbeans и ещё с парой мнее известных IDE. Видел и энтерпрайз проекты, над которыми работали сотни разработчиков, и опен сорс решения, крутящиеся на сотне серверов. И видел как прекрасно растут системы, написанные на Java, Scala, Python, Erlang и десятке других языков, набираемых в IDEA, Vim, Emacs и просто в блокноте.
Ваши рассуждения в моем понимании совершенно не вяжутся с вашей квалификацией. После 5 лет в энтерпрайзе люди обычно не утверждают, что регулярный рефакторинг бывает нужен, чтобы «подчищать за обезьянками», а для создания качественного кода «достаточно понимать всего пару принципов». Может быть, я просто не дорос до вашего уровня. Допускаю. Или я вообще не понял, что вы имели в виду и нас унесло от изначальной темы.
В любом случае, этот спор совершенно бесплоден. И продолжать его я смысла не вижу, о чем бы он ни шел. Простите за потраченное время.
В любом случае, этот спор совершенно бесплоден. И продолжать его я смысла не вижу, о чем бы он ни шел. Простите за потраченное время.
регулярный рефакторинг бывает нужен, чтобы «подчищать за обезьянками», а для создания качественного кода «достаточно понимать всего пару принципов»
Эх, ну вот опять вы читаете больше, чем написано… Ну да ладно, спор действительно пора заканчивать. Приятного вечера или что там сейчас в вашей временной зоне.
дебаггер не может сделать step backКстати, вот за это я их и не люблю. Особенно «весел» дебаггинг при отладке серверных систем, которые стартуют по 10 минут — приходится кучу раз делать запрос и кучу раз перестартовывать (по 10 минут каждый) чтобы выяснить причину. Был бы step back — цены бы такому дебаггеру не было.
Вообще такая «REPL-ориентированная» разработка напоминает разработку на форте из книжек по форту.
А можно пример IDE где удобно XML редактировать?
А что вам «удобно»? :) Вот, попробуйте это: marketplace.eclipse.org/content/rinzo-xml-editor
Новое название для Word-а IDE для написания служебных записок :)
А если серьезно, то вы абсолютно правы.
А если серьезно, то вы абсолютно правы.
Стиль работы может быть очень разным как для разных ЯП, так и в пределах одного ЯП, но для разных задач.
- Для JavaScript в принципе не может существовать полноценной IDE, потому что JS — очень-очень динамический. Ни контекстные подскази толком не сделаешь (разве что вывалить все названия какие встречаются в коде), ни рефакторинги автоматизируешь, потому что без выполнения программы практически невозможно точно узнать что делает какой-то кусок кода. А с такими ограничениями от IDE толком ничего и не остаётся — подсветка, кнопки для запуска разных задач и получаем в итоге тот же Sublime.
- У всяких Java и C# таких ограничений почти нет (в C# такие есть динамические типы, но очень-очень не повсеместно). Поэтому и по коду прыгать удобно — всегда понятно откуда берётся какое-то имя, и рефакторинги замечательно работают, т.к. разночтений в принципе быть не может. В этом случае IDE даёт намного больше, чем в первом.
Что-то не так с моим комментарием?
Нет, это моё мнение по поводу вашего «мы имеем дело с обыкновенной вкусовщиной». Вкусовщина безусловно имеет место, но она не на первом месте. На первом месте — специфика ЯП и техническая возможность сделать какие-то плюшки для него. Рассмотрены 2 условных семейства ЯП, показано, что «вкусовщина» более применима к JS и подобным (IDE почти равно редактору с плагинами), а для C#/Java редактором будет пользоваться только извращенец (IDE даёт очень многое).
Резюмируя: вкусовщина не на первом месте.
Резюмируя: вкусовщина не на первом месте.
Хакерский романтизм и шило в заднице — не более.
Он здесь уместен. Есть программисты, которые просто работают за зарплату. Есть программисты, которым нравится работать круто — тренироваться делать фичи быстрее и качественнее. А есть программисты, которые любят возиться с инструментами надеясь, что как только оно заработает, качество их работы вырастет на порядок и вот тогда-то уж они запрограммируют всё-всё-всё.
Та толпа извращенцев — из 3-ей категории.
Та толпа извращенцев — из 3-ей категории.
vim и emacs уникальные редакторы. Подход к редактированию текста там радикально отличается от подхода к редактированию текста в блокноте. Большинство IDE это в общем блокнот обвешанный фичами. Редактировать текст там откровенно неудобно.
Спор между IDE и vim с emacs это не спор между текстовыми редакторами и IDE. Это спор между разными подходами к редактированию текста. Если бы в IDE был нормальный текстовый редактор — адепты vim и emacs перешли бы на эту IDE не задумываясь.
Поэтому и тащат eclipse в vim и emacs. Чтобы было нормальное редактирование текста плюс возможности IDE.
Спор между IDE и vim с emacs это не спор между текстовыми редакторами и IDE. Это спор между разными подходами к редактированию текста. Если бы в IDE был нормальный текстовый редактор — адепты vim и emacs перешли бы на эту IDE не задумываясь.
Поэтому и тащат eclipse в vim и emacs. Чтобы было нормальное редактирование текста плюс возможности IDE.
Для JavaScript в принципе не может существовать полноценной IDE
С этой задачей вполне успешно справляется любой современный браузер. Там есть всё — и debug, и watch, и автодополнение, и даже измерение производительности.
без выполнения программы практически невозможно точно узнать что делает какой-то кусок кода
Это лишь означает, что язык — дрянь. Но всё, что можно было выжать (я выше перечислил), выжали. Это — уже больше, чем позволяла любая самая крутая IDE для C++ 15 лет назад.
в C# такие есть динамические типы
Это не мешает определить типы данных на этапе компиляции. А значит рефакторинг будет работать.
Мне кажется, у вас либо мало опыта, либо просто какой-то bad luck с тем, что вы называете редактрами. Например:
Мне хватило 15 секунд, чтобы нагуглить, что нумерация строк включается командой `M-x linum-mode`. Хотя лично мне всегда хватало номера строки и колонки в статусной строке внизу активного окна. Подсказки и автодополнения зависят от мода — практически во всех специализированных модах, которые я использую — они есть. Поиск нужного файла тоже много где реализован, плюс, насколько я помню, доступен в виде отдельного мода (могу поискать, если хотите). Key bindings изменяются элементарно на что вам нравится через `(gloabl-set-key ...)` и `(local-set-key ...)`. Дебаггерами практически не пользуюсь, но гугль говорит, что их тоже не хватает.
Не могу говорить за все редакторы, но Emacs при желании — это не только IDE, но и практически полноценная операционная система, просто менее специализированная под конкретные языки, как Visual Studio или Eclipse.
Попробуйте, скажем, включить нумерацию строк в том же emacs!
Мне хватило 15 секунд, чтобы нагуглить, что нумерация строк включается командой `M-x linum-mode`. Хотя лично мне всегда хватало номера строки и колонки в статусной строке внизу активного окна. Подсказки и автодополнения зависят от мода — практически во всех специализированных модах, которые я использую — они есть. Поиск нужного файла тоже много где реализован, плюс, насколько я помню, доступен в виде отдельного мода (могу поискать, если хотите). Key bindings изменяются элементарно на что вам нравится через `(gloabl-set-key ...)` и `(local-set-key ...)`. Дебаггерами практически не пользуюсь, но гугль говорит, что их тоже не хватает.
Не могу говорить за все редакторы, но Emacs при желании — это не только IDE, но и практически полноценная операционная система, просто менее специализированная под конкретные языки, как Visual Studio или Eclipse.
Вот именно — гуглится. Т.е. даже такую элементарную вещь включить без помощи гугла — никак. А что говорить о более сложных вещах?
Поиск файла — да. В том же projectile работает. Только я с ним 2 дня медитировал, пока разобрался со способами индексации и удалось получить приемлемую скорость работы этой функции.
Тем не менее, мне нравится с этим ковыряться — даже про lisp кое-что почитывать начал. Но не всегда есть время и желание гуглить 2 дня для добавления нужного функционала. Я поэтому пока с отладчиком в emacs и не связываюсь.
которой не хватает хорошего текстового редактора :)
Поиск файла — да. В том же projectile работает. Только я с ним 2 дня медитировал, пока разобрался со способами индексации и удалось получить приемлемую скорость работы этой функции.
Тем не менее, мне нравится с этим ковыряться — даже про lisp кое-что почитывать начал. Но не всегда есть время и желание гуглить 2 дня для добавления нужного функционала. Я поэтому пока с отладчиком в emacs и не связываюсь.
Emacs при желании — это не только IDE, но и практически полноценная операционная система
которой не хватает хорошего текстового редактора :)
Вот именно — гуглится. Т.е. даже такую элементарную вещь включить без помощи гугла — никак. А что говорить о более сложных вещах?
Эмм… А как это должно было быть? Если гуглить — это, по-вашему, долго и сложно, то можно просто начать набирать `M-x line-...`, и Emacs вам сразу выдаст 2 режима для номера строк. Но всё-таки с гуглом удобней, как для Emacs, так и для IDE.
Поиск файла — да. В том же projectile работает. Только я с ним 2 дня медитировал, пока разобрался со способами индексации и удалось получить приемлемую скорость работы этой функции.
Опять же, за 30 секунд нагуглил родную функцию `locate`, которая находит файл внутри какой-то директории. Загуглил — потому что для того же Python у меня автоматически включается умная подстановка пути по `C-x f`.
которой не хватает хорошего текстового редактора :)
Старая и несправедливая шутка :) Emacs — это непривычный текстовый редактор, да, но плохим его назвать точно нельзя.
Если гуглить — это, по-вашему, долго и сложно, то можно просто начать набирать `M-x line-...`,
Это не «сложно и долго». Это — излишне сложно и долго. Зачем мне вообще знать эту команду? Почему не мышкой? Нет, я понимаю, конечно, почему в emacs-е это так. Но это же является недостатком для промышленного использования — слишком сложно.
Emacs — это непривычный текстовый редактор, да, но плохим его назвать точно нельзя.
От org-mode я вообще в восторге!
Это не «сложно и долго». Это — излишне сложно и долго. Зачем мне вообще знать эту команду? Почему не мышкой? Нет, я понимаю, конечно, почему в emacs-е это так. Но это же является недостатком для промышленного использования — слишком сложно.
15 секунд и гугль раз в жизни — это слишком сложно? Ммм…
При таком раскладе гуглопоиск должен быть встроен в emacs из коробки.
Зачем?
Впрочем, если хочется, функцию для этого написать недолго.
Впрочем, если хочется, функцию для этого написать недолго.
Не из коробки, но идея интересная, и кому-то она в голову уже пришла. Особенно интересной кажется вариация с шорткатом для поиска по сообщениям об ошибках.
Это не «сложно и долго». Это — излишне сложно и долго
А программировать вы тоже начали методом тыка, или все же прочли пару мануальчиков?
С каких это пор программирование и использование программ — равносильные понятия?
С тех пор, с каких для эффективной работы нужно уметь пользоваться инструментами. Как считаете, можно быть хорошим столяром, не умея пользоваться молотком?
Не помню, чтобы мне приходилось гуглить, чтобы научиться пользоваться молотком. Или изучать устройство молотка. Или подготавливать специальным образом руки к работе с молотком. Выше ключевое слово — «излишне».
Вы уверены, что учились пользоваться молотком «без гугла», т.е. абсолютно самостоятельно, извлекая информацию об этом деле только из молотка, досок и гвоздей? Ни разу даже не видели, как их забивает кто-нибудь более опытный, прежде чем первый раз попробовать самому?
Видел, конечно. И этой информации хватило.
ЧТД. А если смотреть, как кто-нибудь работает с Emacs, Visual Studio или Photoshop — те функции, которыми они активно пользовались, гуглить, вероятно, тоже не понадобится. Но, да, смотреть придётся более внимательно, к молотку наше подсознание эволюция лучше подготовила, чем к мэйнстримным устройствам управления компьютером.
Возможно вы не поняли, но «молоток» в моем примере, это лишь абстракция, обозначающая инструмент мастера. Замените «молоток» в вашей голове на фрезерный станок TF 200 SE.
Почему не мышкой?
Мышкой куда? Попробовал включить в PyCharm те же самые номера строк, без гугла не осилил. А M-x line-<TAB> — вероятно, догадался бы. Впрочем, существенным недостатком PyCharm это не считаю, потому как гугл — это несложно и недолго.
Два раза shift или ctrl+shift+a и там можно искать интересующее. Например, show numbers.
О, спасибо. Вот что в меню Navigate перечислены не все команды поиска, а к невзрачной серой лупе на тулбаре стоит присмотреться отдельно, я и не догадался. И инструкцию не прочёл — кажется, в этом треде не зазорно в таком признаться.
Но, чёрт возьми, это же прямо супермаркет какой-то: самый ходовой товар — не на полке с аналогичными, а на другом конце зала.
Но, чёрт возьми, это же прямо супермаркет какой-то: самый ходовой товар — не на полке с аналогичными, а на другом конце зала.
Но, чёрт возьми, это же прямо супермаркет какой-то: самый ходовой товар — не на полке с аналогичными, а на другом конце зала.
Не соглашусь. В 9х% случаев знаешь где искать (в именах файлов, в текущем файле, в именах опций, ect) и вызываешь соответствующий шорткат. Дабл шифт лично я использую крайне редко. Когда действительно не понятно, «куды бечь».
В Android Studio ПКМ по месту, где должны быть номера, Show line numbers. Зачем там нужен был гугл, непонятно.
[irony] EvilMode добавляет нормальный редактор [/irony]
Просто воспринимайте емакс как конструктор текстового редактора. И если вам некогда возиться с конструктором, то логично использовать IDE.
Я наверно совсем не труЪ emacs-пользователь, но в целом я поднастроил себе редактор всего за месяц… с тех пор фундаментальных изменений больше не вносил и мне моего конфига вполне хватает) Правда пришлось смириться с тем, что некоторые иногда удобные фичи в emacs настроить нельзя.
я поднастроил себе редактор всего за месяц
Всего… за месяц…
Вы знаете, я, конечно, не скажу за вас — не знаю, что вы там делаете в нем и какие тонкости решаете, но когда я настраивал себе eclipse, чтобы он нормально код форматировал (не переносил 81-й символ на новую строку и т п...) и немного хоткеи менял, а потом конфигурил в нем проектный файл для C++-проекта, то на всё ушло пара часов и мне это показалось очень долго.
1) Месяц настройки — это н значит, что я месяц настраивал редактор прежде, чем начал им пользоваться. Это значит, что я все свои хотелки добавлял по мере надобности в течении примерно месяца)
2) Вот конкретно eclipse я несколько раз пробовал использовать, и всегда он мне казался каким-то неудобным и нелогичным. До emacs я исопльзовал QtCreator, который меня устраивал всем, кроме того, что в нем нельзя было работать без использования мыши. Собственно из-за этого я и перешел с него на emacs и даже несмотря на отсутствие некоторых фич, которые были в креэйторе, работа в emacs все равно оказалась удобней.
2) Вот конкретно eclipse я несколько раз пробовал использовать, и всегда он мне казался каким-то неудобным и нелогичным. До emacs я исопльзовал QtCreator, который меня устраивал всем, кроме того, что в нем нельзя было работать без использования мыши. Собственно из-за этого я и перешел с него на emacs и даже несмотря на отсутствие некоторых фич, которые были в креэйторе, работа в emacs все равно оказалась удобней.
Eclipse мне тоже поначалу показался нелогичным. Просто, у него довольно высокий «порог вхождения». Он на первом же уровне формирует у пользователя нетривиальные понятия типа workspace, debug configuration и прочее. Но зато как только вы поймете смысл всего этого, вы увидите четкую структурированность и железную логичность архитектуры. В Idea, на первый взгляд, более логичную, многие фичи прикручены в весьма странных местах в угоду новичкам, которые не желают привыкнуть к идеологии системы. Так как я всё всегда изучаю «от устройства к внешнему виду», мне eclipse ближе. Но на emacs я, всё же, не согласен.
В Eclipse нет ничего нетривиального, там есть нелогичное. И разница в том, что к eclipse нужно «привыкать к идеалогии системы», а в emacs все настраивается по своему вкусу.
Что вам там показалось нелогичным? Мне правда интересно. Просто хотя бы какой-то конкретный пример.
Мне, на самом деле, Emacs вообще не кажется конкурентом eclipse-а в плане работы с Java кодом. Слишком несопоставимые возможности.
И я считаю, что если на данном этапе какая-то IDE для своего языка сопоставима по возможностям с Vim и Emacs, то она попросту недоделана.
Мне, на самом деле, Emacs вообще не кажется конкурентом eclipse-а в плане работы с Java кодом. Слишком несопоставимые возможности.
И я считаю, что если на данном этапе какая-то IDE для своего языка сопоставима по возможностям с Vim и Emacs, то она попросту недоделана.
Я последний раз Eclipse открывал года 3-4 назад, т.ч. конкретных примеров сейчас назвать не смогу. Ну и да. я её не для Java, а для C++ использовал.
Для работы с C++ Eclipse необходимо настраивать. Увы, CDT при всей своей универсальности далек от совершенства. Но при этом я не знаю ни одной другой среды, настолько всеядной в плане парадигм и компиляторов. Хотите mingw? Окей. Хотите MS C++? Без проблем. Хотите makefile? Вам сгенерировать? Или свой подложите? Хотите кросс-платформенное приложение одновременно на C, Java и Фортране? Да пожалуйста! Только 3 плагина поставьте в среду, да настроечки пропишите. И будет вам во всех трех языках intellisense.
Вы знаете, что меня раздражает в Eclipse на данный момент? То, что Ctrl+Click по декларации native-функции в Java не вызывает имплементацию этой функции в JNI-слое на C. И, да, я считаю, что это из разряда «мелких бриллиантов»
Вы знаете, что меня раздражает в Eclipse на данный момент? То, что Ctrl+Click по декларации native-функции в Java не вызывает имплементацию этой функции в JNI-слое на C. И, да, я считаю, что это из разряда «мелких бриллиантов»
который меня устраивал всем, кроме того, что в нем нельзя было работать без использования мыши
Вот этот аргумент меня всегда больше всего радовал. Чем не угодила мышь? Только не отвечайте мне, что с ней медленно. Попробуйте про медленность мыши рассказать вашему соседу-старкрафтеру :)
Я впервые услышал про «неудобную и медленную мышь» от человека, который был моим преподавателем информатики и который был старше моих родителей лет на 5-10. Он сам пользовался мышью так: клал на нее пальцы, пододвигал ее к нужному месту на экране, потом перекладывал палец на кнопку и торжественно (иначе не сказать) эту кнопку жал.
Еще я от него слышал, что для того, чтобы попасть мышью по кнопке так же ловко, как пальцем, надо, чтобы эта кнопка занимала четверть экрана. При его навыках владения этим инструментом, в его поколении, когда мышами можно было гвозди заколачивать, это простительно.
Разумеется, набор текста пальцами на клавиатуре быстрее, чем мышью на экранной клавиатуре. Но вот с человеком, который набирает текст одним пальцем, я бы посоревновался. А вы часто нажимаете больше двадцати хоткеев в минуту?
Лично я при написании программ процентов 80 времени думаю и процентов 20 — пишу. И нажать что-то мышкой (с которой я общаюсь с 12 лет, хотя до этого у меня был комп совсем без мышки) для меня гораздо проще, чем учить 100500 хоткеев.
В emacs не надо учить 100500 хоткеев, их можно настроить так, чтобы нажимать не задумываясь.
Ну и лично у меня в 80% разудмий входит еще изучение логов работы программы, написание мелких скриптов для их обработки на python/perl, написании заметок на основе полученных данных и тд и тп, т.ч. все равно в этой работе присутсвует процессинг текста.
Ну и лично у меня в 80% разудмий входит еще изучение логов работы программы, написание мелких скриптов для их обработки на python/perl, написании заметок на основе полученных данных и тд и тп, т.ч. все равно в этой работе присутсвует процессинг текста.
Согласен с вами. Вопрос был лишь в том, чем могла помешать мышь. Моё утверждение — ничем.
Помешать — ничем, но без неё удобней.
В emacs не надо учить 100500 хоткеев
Я знаю порядка 20 горячих клавиш в eclipse. А если бы все функции, которые я там использую я делал с помощью хотев, пришлось бы знать около пятидесяти. Или ста.
Я не люблю писать консольные команда даже если это вим-овские ":blabla". Я даже :wq учил некоторое время, потому что GIT предлагает Vim в качестве стандартного редактора сообщений.
Моя голова забита совсем другими вещами.
Вообще, конечно, зря я в этот спор влез. Просто настроение было такое угрюмое.
Ответьте ровно н один вопрос: на какую функцию в eclipse, где на каждый чих переназначаемая горячая клавиша, НЕЛЬЗЯ назначить горячую клавишу? Назовите хоть одну.
Ну вот типичная ситуация: у меня программа выплевывает лог в консоль, после завершение программы я регуляркой хожу по логам и анализирую их. Все это я делаю не выходя из emacs и не отрывая пальцев от клавиатуры, в Eclipse я так смогу сделать?
Кхм… ну, допустим. Логи, конечно, можно парсить, если формат известен. А если у вас просто какой-то лог… Мне никогда не приходилось с ним делать что-то сложнее поиска.
Жму Ctrl+F7 (переход к окошку с консолью), затем Ctrl+F, ставлю галку «Regular expressions» (вот тут удобнее мышью, но она запоминается) — и вот у меня поиск в логе по регуляркам.
Это — оно?
Жму Ctrl+F7 (переход к окошку с консолью), затем Ctrl+F, ставлю галку «Regular expressions» (вот тут удобнее мышью, но она запоминается) — и вот у меня поиск в логе по регуляркам.
Это — оно?
Если вы запустились из Eclipse, то и консоль (out) будет направлен в него. Если не из Eclipse — нужно будет как-то буфер перекидывать. Хотя тут могу ошибаться, но вроде это общее правило для основной тройки Java IDE (Idea, Eclipse, Netbeans).
PS опять же не уверен, что Eclipse этим занимается, но вот Idea ещё и подсветит знакомые классы в стектрейсе и позволит по клику переходить в точку вызова.
PS опять же не уверен, что Eclipse этим занимается, но вот Idea ещё и подсветит знакомые классы в стектрейсе и позволит по клику переходить в точку вызова.
Если вы запустились из Eclipse
Простите, а вы рассматриваете ситуацию, при которой приложение, разрабатываемое в IDE, запускается не из нее? Простите… а зачем вы так делаете? То есть мне кажется, что запустить изнутри можно абсолютно всегда, плюс отладчик автоматом цепляется…
Какой смысл запускать извне?
Idea ещё и подсветит знакомые классы в стектрейсе
Eclipse — тоже
Что до меня — то мне без разницы, какие гадкие использовать — родные или настроенные. Я через день забуду даже те, которые придумал сам.
У нас работают… те кто копировать-вставить вызывают из меню, мышкой. Но хоткеи им все равно не помогут.
ДА, некоторое количество часто употребляемых хоткеев все-таки необходимо выучить для эффективной работы.
Но я боюсь представить каковы требования к эффективности работы(ввода текста программы?) если для этого необходимо знать сотни хоткеев… И что это за настолько разнообразная работа.
ДА, некоторое количество часто употребляемых хоткеев все-таки необходимо выучить для эффективной работы.
Но я боюсь представить каковы требования к эффективности работы(ввода текста программы?) если для этого необходимо знать сотни хоткеев… И что это за настолько разнообразная работа.
Я утверждал только то, что мышь — полезный инструмент при разработке. И идеология «надо всё делать без мыши» ущербна.
И идеология «надо всё делать без мыши» ущербна.
И таки чем она ущербна не понятно. Вы её в полной мере пробовали, чтобы это утверждать?:)
Вот я и с мышкой N лет работал, потом без мышки и по личному опыту пришел к выводу, что без мыши лично мне удобней… как и многим другим пользователям emacs/vim.
Вы меня не поняли.
Мое утверждение 1: eclipse поддерживает хоткеи для всего подряд. И в нем можно при желании работать на клавиатуре. Возможно, совсем без мыши обойтись не удастся, но 90% работы точно можно делать без нее, если это хочется. Также в нем можно настроить хоткеи по своему вкусу. Всё можно.
Мое утверждение 2: Vim не позволяет выбирать пункты из меню мышкой, тем самым навязывая пользователю стиль работы «keyboard-only», подходящий далеко не всем. К тому же, он предлагает свой совершенно шизофренический дизайн с двумя режимами «пикать и всё портить», перемещение по тексту клавишами, для этого не предназначенными и под всё это подводится теоретическая база (смехотворная, на мой взгляд), что передвиганное рук по клавиатуре занимает время, которое можно сэкономить.
Мое утверждение 3: навязывание ограничений пользователю говорит либо об ущербности системы, либо об ее недоработанности.
И еще одно соображение: если в чьей-то работе можно сэкономить заметное время за счет избавления от передвигания пальцев по клавиатуре, значит этот человек либо супермен (и тогда он достигнет успеха в любом редакторе текста), либо машинистка. Моя средняя скорость набора кода (если усреднять за целый день работы) составляет несколько десятков символов в минуту. И то, если день «задался».
Разумеется, я допускаю, что кому-то редакторы типа Emacs/Vim удобнее. Иначе бы не о чем было спорить. Я лишь хочу дать понять, что переход с них на полноценную IDE существенно вероятнее улучшит вашу эффективность, нежели наоборот.
Мое утверждение 1: eclipse поддерживает хоткеи для всего подряд. И в нем можно при желании работать на клавиатуре. Возможно, совсем без мыши обойтись не удастся, но 90% работы точно можно делать без нее, если это хочется. Также в нем можно настроить хоткеи по своему вкусу. Всё можно.
Мое утверждение 2: Vim не позволяет выбирать пункты из меню мышкой, тем самым навязывая пользователю стиль работы «keyboard-only», подходящий далеко не всем. К тому же, он предлагает свой совершенно шизофренический дизайн с двумя режимами «пикать и всё портить», перемещение по тексту клавишами, для этого не предназначенными и под всё это подводится теоретическая база (смехотворная, на мой взгляд), что передвиганное рук по клавиатуре занимает время, которое можно сэкономить.
Мое утверждение 3: навязывание ограничений пользователю говорит либо об ущербности системы, либо об ее недоработанности.
И еще одно соображение: если в чьей-то работе можно сэкономить заметное время за счет избавления от передвигания пальцев по клавиатуре, значит этот человек либо супермен (и тогда он достигнет успеха в любом редакторе текста), либо машинистка. Моя средняя скорость набора кода (если усреднять за целый день работы) составляет несколько десятков символов в минуту. И то, если день «задался».
Разумеется, я допускаю, что кому-то редакторы типа Emacs/Vim удобнее. Иначе бы не о чем было спорить. Я лишь хочу дать понять, что переход с них на полноценную IDE существенно вероятнее улучшит вашу эффективность, нежели наоборот.
Мое утверждение 2: Vim не позволяет выбирать пункты из меню мышкой, тем самым навязывая пользователю стиль работы «keyboard-only», подходящий далеко не всем. К тому же, он предлагает свой совершенно шизофренический дизайн с двумя режимами «пикать и всё портить», перемещение по тексту клавишами, для этого не предназначенными и под всё это подводится теоретическая база (смехотворная, на мой взгляд), что передвиганное рук по клавиатуре занимает время, которое можно сэкономить.
Vim-стиль с модальным редактированием мне тоже не особо нравится, мне больше нравится иметь возможность сделать все что в голову взбредет прямо сейча.
Мое утверждение 3: навязывание ограничений пользователю говорит либо об ущербности системы, либо об ее недоработанности.
В emacs нет ограничений, им можно пользоваться как обыкновенным редактором, орудуя мышкой+клавиатурой если так больше нравится) А вот у большинства IDE есть предел, выше которого под себя настроить среду уже нельзя и придется привыкать к тому, что есть.
Я лишь хочу дать понять, что переход с них на полноценную IDE существенно вероятнее улучшит вашу эффективность, нежели наоборот.
Практика показывает, что мало кто в качестве первого редактора кода использует vim/emacs. Подавляющее большинство переходит на такие редакторы с тяжелых IDE. Вы и правда считаете, что все эти люди — городские сумасшедшие, которые переходят на подобные редакторы в ущерб удобству?
Вы и правда считаете, что все эти люди — городские сумасшедшие, которые переходят на подобные редакторы в ущерб удобству?
А вот с этого места я бы уточнил.
Я видел студентов, которые, ползав пару недель eclipse в учебном проекте и не изучив и десятой части его возможностей, бросали его со словами «да ну его, он кривой».
Видел людей, которые писали на python и использовали при этом sublime. На мой вопрос, чем не угодил PyCharm, ответ был либо «да ну его, он тяжелый/сложный», либо «хрен знает, не пробовал».
Я видел около сотни разработчиков, которые писали на Java проекты по несколько десятков или сотен классов. Все они использовали Idea или Eclipse. Многие в совершенстве владели Vim-ом. Ни одному из них даже в кошмаре не могло бы присниться, чтобы редактировать Java-код не в IDE.
Из этого я сделал вывод о том, что во-первых, мало знаю пижонство на больших проектах (думаю, там картина схожая, хотя допускаю, что PyCharm хуже, чем Idea), а во-вторых, не встретив ни одного человека, ушедшего с хорошо известной ему IDE на что-то другое только из-за возможности никогда не браться за мышку, склонен полагать, что таких людей исчезающие мало. И я бы с радостью пообщался с таким — очень интересны его соображения.
Кстати, одно время действительно приходилось редактировать большие Java-проекты без IDE. Это было когда памяти в компе было еще 1 Гигабайт, а Эклипс под проект хотел съесть 800 Мегов. Вот тогда приходилось «изгаляться» — грузить частями, подкладывать jar-файлы… Но те времена уж лет 5 как минули.
Вот и начните с этой фразы «без мыши лично мне удобней». Всё остальное — профанация.
Я вот пользуюсь и мышью и клавиатурой. Иногда для одних и тех же действий (вплоть до выбора файла в окошке). Всё зависит от текущего контекста — держусь за мышку, значит мышкой поконтролю, держусь за клавиатуру и скать долго до фейла не придётся — буду работать с клавиатурой.
Я вот пользуюсь и мышью и клавиатурой. Иногда для одних и тех же действий (вплоть до выбора файла в окошке). Всё зависит от текущего контекста — держусь за мышку, значит мышкой поконтролю, держусь за клавиатуру и скать долго до фейла не придётся — буду работать с клавиатурой.
Так я вообще не утверждал, что всем без мыши удобней, это меня тут пытаются убедить в том, что работа без использования мыши ущербна)
з.ы. в emacs таки при желании можно и мышкой тыкать, менюшки и прочие свистелки упрощающие жизнь любителям этого контроллера присутствуют)
з.ы. в emacs таки при желании можно и мышкой тыкать, менюшки и прочие свистелки упрощающие жизнь любителям этого контроллера присутствуют)
Что — профанация? Какой смысл спорить о том, что удобнее лично вам? Я, может, левой ногой на тачскрине код ввожу. Мне, может, так думается лучше…
Спорить можно о статистике. И об эффективности.
Люди, которые утверждают, что новичка-программиста следует обучить Vim-у и тогда он будет ужас как эффективен, неправы. Это разве профанация?
Люди, которые считают, что Emacs лучше, потому что в нем плагин пишется за 10 минут, неправы, потому что плагин должен писаться не тем же самым человеком, который его использует, а совсем другим. И только при таком разделении труда работа пойдет эффективно.
И, наконец, люди, которые считают, что при увеличении проекта его будет так же легко контролить в Emacs, как в Eclipse, неправы. Они, очевидно, просто не имели дело с по-настоящему крупными проектами. И просто смущают умы начинающих, перед которыми стоит выбор, какую среду разработки изучать и которым может обманчиво показаться, что текстово-консольный интерфейс симпатичнее, а значит — удобнее.
Вот тут я с вами абсолютно согласен. Но ведь и спорил я не с вами.
Спорить можно о статистике. И об эффективности.
Люди, которые утверждают, что новичка-программиста следует обучить Vim-у и тогда он будет ужас как эффективен, неправы. Это разве профанация?
Люди, которые считают, что Emacs лучше, потому что в нем плагин пишется за 10 минут, неправы, потому что плагин должен писаться не тем же самым человеком, который его использует, а совсем другим. И только при таком разделении труда работа пойдет эффективно.
И, наконец, люди, которые считают, что при увеличении проекта его будет так же легко контролить в Emacs, как в Eclipse, неправы. Они, очевидно, просто не имели дело с по-настоящему крупными проектами. И просто смущают умы начинающих, перед которыми стоит выбор, какую среду разработки изучать и которым может обманчиво показаться, что текстово-консольный интерфейс симпатичнее, а значит — удобнее.
держусь за мышку, значит мышкой поконтролю
Вот тут я с вами абсолютно согласен. Но ведь и спорил я не с вами.
И, наконец, люди, которые считают, что при увеличении проекта его будет так же легко контролить в Emacs, как в Eclipse, неправы. Они, очевидно, просто не имели дело с по-настоящему крупными проектами.
На 700K строк кода в ~3500 файлах — это достаточно крупный проект? Если да. то могу заверить, что в emacs полет нормальный :)
Ну, как скажете. Я бы так не смог. И не посоветовал бы никому. Разве только альтернатив никаких нет.
Альтернативы есть разумеется, до этого я пользовался QtCreator'ом (т.к. под linux это пожалуй самая адекватная IDE для C/C++)… в итоге перешел на emacs, таки ради того, чтобы не прыгать по окнам между IDE/консолью/файл-браузером/редактором для скриптов и чтобы не пользоваться мышкой.
Можно в Emacs переименовать переменную или класс по контексту?
Или, хотя бы, осуществить контекстный поиск: пусть у меня в одном файле есть двадцать переменных «iter» в разных функциях — я могу получить список вхождений КОНКРЕТНОЙ из них, который не включает остальные, основывается на реальном парсинге кода, а не на регулярках, и шагать по нему?
Можно написать (хрен с ним, пусть с клавиатуры) что-то типа «add watch», чтобы потом, идя по коду отладчиком, видеть значение переменной в окошечке сбоку?
А как делается навигация типа «Ctrl+Click», то есть прыжок к декларации? И работает ли он для переменных, а не только для классов?
Это — список фич, без которых я бы работать нормально не смог. Это всё уже есть?
А вызвать дерево вызовов функции (функции, которые вызывают функции, которые вызывают эту функцию) можно?
А можно такое же дерево для наследования классов?
Или, хотя бы, осуществить контекстный поиск: пусть у меня в одном файле есть двадцать переменных «iter» в разных функциях — я могу получить список вхождений КОНКРЕТНОЙ из них, который не включает остальные, основывается на реальном парсинге кода, а не на регулярках, и шагать по нему?
Можно написать (хрен с ним, пусть с клавиатуры) что-то типа «add watch», чтобы потом, идя по коду отладчиком, видеть значение переменной в окошечке сбоку?
А как делается навигация типа «Ctrl+Click», то есть прыжок к декларации? И работает ли он для переменных, а не только для классов?
Это — список фич, без которых я бы работать нормально не смог. Это всё уже есть?
А вызвать дерево вызовов функции (функции, которые вызывают функции, которые вызывают эту функцию) можно?
А можно такое же дерево для наследования классов?
Или, хотя бы, осуществить контекстный поиск: пусть у меня в одном файле есть двадцать переменных «iter»
Конкретно это (Find all references) в MSVS из коробки работает не то что бы очень хорошо. Вываливает все что есть в солюшене без разбора. Возможно, я неправильно пользуюсь.
MSVS — худшая из известных мне IDE для C++. Какой смысл о ней вообще говорить? Я знаю и люблю Eclipse. Там это работает прекрасно.
Смысл говорить об MSVS возникает тогда, когда проект построен именно в ней.
Есть ли в Eclipse «Parallel Stacks» окно в дебаггинге? В 13й студии очень помогает при дебаге мультитрединга.
Есть ли в Eclipse «Parallel Stacks» окно в дебаггинге? В 13й студии очень помогает при дебаге мультитрединга.
Честно говоря, не знаю. Есть расширения для параллельной отладки… Вот: help.eclipse.org/kepler/index.jsp?topic=%2Forg.eclipse.ptp.doc.user%2Fhtml%2F06parDebugging.html
Но, думаю, это не совсем то, о чем вы говорите.
Но, думаю, это не совсем то, о чем вы говорите.
Я сам не то чтобы большой любитель MSVS но в данном случае это выглядит несколько более удобно.
Хм, вроде бы даже «голый» GDB умеет по тредам скакать.
В 14 версии переделали, теперь гораздо удобнее (декларация отдельно и все обращения именно к этой декларации ветками к ней, если где-то переопределена, то это будет новый корень со своими ветками).
Можно в Emacs переименовать переменную или класс по контексту?
Или, хотя бы, осуществить контекстный поиск: пусть у меня в одном файле есть двадцать переменных «iter» в разных функциях — я могу получить список вхождений КОНКРЕТНОЙ из них, который не включает остальные, основывается на реальном парсинге кода, а не на регулярках, и шагать по нему?
С семантическим анализом кода в emacs действительно не все хорошо. Для C++ есть semantic и какие-то моды. работающие через clang, но я ими не пользуюсь, т.к. они кривые. Мне вполне хвает для этих операций grep'а.
Можно написать (хрен с ним, пусть с клавиатуры) что-то типа «add watch», чтобы потом, идя по коду отладчиком, видеть значение переменной в окошечке сбоку?
Есть неплохой фронтенд к gdb, по моему даже лучше, чем в QtCreator.
А как делается навигация типа «Ctrl+Click», то есть прыжок к декларации? И работает ли он для переменных, а не только для классов?
Тотже ctags или semantic есть, народ пользуется, но лично я как-то и без этого обхожусь.
А вызвать дерево вызовов функции (функции, которые вызывают функции, которые вызывают эту функцию) можно?
А можно такое же дерево для наследования классов?
Вероятно как-то можно, но мне хватает grep'а для таких вещей.
Ну как?.. Скажите мне, КАК вы умудряетесь ориентироваться в проекте на 3500 файлов без семантического поиска/навигации? Что вы в нем делаете? Я не понимаю. Может, я правда дурак и мозги у меня сушеные.
Я без быстрой и качественной навигации буду только разбираться в связях в таком проекте две недели…
Я без быстрой и качественной навигации буду только разбираться в связях в таком проекте две недели…
Основной инструмент для поиска по коду у меня — это grep (ну и GDB, если хочу посмотреть помимо прочего, какие данные куда передаются), а всю семантику проекта я в голове держу.
На самом деле при некоторой сноровке grep'ом получается ходить по проекту довольно быстро. Хотя, будь в emacs качественно реализованный семантический парсер, я бы им пользоваля.
На самом деле при некоторой сноровке grep'ом получается ходить по проекту довольно быстро. Хотя, будь в emacs качественно реализованный семантический парсер, я бы им пользоваля.
Основной инструмент для поиска по коду у меня — это grep
Я слишком избалован, чтобы при редактировании кода лезть в консоль всякий раз, когда мне понадобится найти слово. Тем более, что просто найти слово — не фокус в любом редакторе. Я имел в виду именно семантический поиск. Неоднократно сталкивался с Java-проектами, в которых класс с одним и тем же именем присутствует в разных пакетах.
Я слишком избалован, чтобы при редактировании кода лезть в консоль всякий раз, когда мне понадобится найти слово.
Так в emacs не надо никуда лезть, один хоткей и вот ты уже грепаешь)
Я имел в виду именно семантический поиск. Неоднократно сталкивался с Java-проектами, в которых класс с одним и тем же именем присутствует в разных пакетах.
Ну, я в основном пишу на C++, Python и т.д. и очень редко пишу на Java, т.ч. мне грепа вполне хватает.
Просто воспринимайте емакс как конструктор текстового редактора
Если продолжить аналогию с конструктором.
Из лего можно собрать молоток. Он будет похож на молоток. Им можно будет по чему-то удалить. Но вот молотком он не будет и гвозди на стройке забивать не сможет.
Вот я и не уверен, что емакс даже со всеми настроенными плагинами когда-либо сможет дать то же удобство и скорость, что и IDE.
У emacs есть архитектурный недостаток — он однопоточный и асинхронность там добавляется через одно место, поэтому emacs умеет подвисать выполняя простейшие операции типа коментирования кода, если выделенный фрагмент достаточно большой. Вот эта однопоточность не позволяет реализовать большинство функционала IDE.
Если продолжить аналогию с конструктором.Если было бы надо, то, думаю, давно сделали бы специальные детали с твёрдыми вставками и с тяжёлыми вставками…
Из лего можно собрать молоток.
Для проектов использую IDE (PyCharm, WebStorm, XCode). Для просмотра исходников и просто редактирования файлов и текстов использую SublimeText. Vim использую только удалённо на серверах. Хотел перейти на просто редакторы, Vim и SublimeText, но как верно заметил автор, на работе, времени нет искать откуда «ноги растут», cmd+click и уже в нужном месте.
IDE в некотором роде выполняют ту же функцию, что и фреймворки. Да, можно взять и написать всё с нуля. У опытного программиста код получится красивее, меньше, производительнее. Однако гораздо проще и в разы быстрее взять фреймворк.
То же и с IDE. Да, можно взять редактор и законфигурировать его под IDE самостоятельно, по сути занимаясь написанием собственной IDE на базе текстового редактора. У опытного программиста при неограниченном запасе времени получится не хуже. Но гораздо проще взять уже готовую IDE и не заниматься велосипедостроением.
Наличие мощных фреймворков, библиотек и IDE — один из важнейших критериев юзабельности языка программирования. Если для нового распиаренного ЯП предполагается писать код в ST, а враппер для DirectX генерировать ручками (т.к. ни либ, ни фреймворков), то при наличии выбора целесообразнее не гнаться за модой, а обратиться к проверенному решению, где вам не придётся создавать с нуля всю инфраструктуру.
То же и с IDE. Да, можно взять редактор и законфигурировать его под IDE самостоятельно, по сути занимаясь написанием собственной IDE на базе текстового редактора. У опытного программиста при неограниченном запасе времени получится не хуже. Но гораздо проще взять уже готовую IDE и не заниматься велосипедостроением.
Наличие мощных фреймворков, библиотек и IDE — один из важнейших критериев юзабельности языка программирования. Если для нового распиаренного ЯП предполагается писать код в ST, а враппер для DirectX генерировать ручками (т.к. ни либ, ни фреймворков), то при наличии выбора целесообразнее не гнаться за модой, а обратиться к проверенному решению, где вам не придётся создавать с нуля всю инфраструктуру.
У опытного программиста при неограниченном запасе времени получится не хуже.
Как человек, в данный период своей жизни занимающийся анализом кода IDE, ответственным за синтаксический анализ кода введенной программы, ответственно заявляю: туда вложены тысячи (если не десятки тысяч) человеко-часов. И в Eclipse, и в Idea. И у самого опытного программиста, если он один, на это уйдет полжизни.
По моему, единственная проблема редакторов типа Emacs, Vim, из-з которой они проигрывают в некоторых аспектах полноценным IDE, состоит в том, что большинство расширений довольно кустарного качества, а часть функционала полноценных IDE вообще не реализовано (типа того-же пресловутого автокомплита).
При этом никто особо не торопится вкладываться в качественную доработку этих редакторов до состояния IDE, вместо этого выпуская 100500-ю IDE на базе кривой эклипсы.
При этом никто особо не торопится вкладываться в качественную доработку этих редакторов до состояния IDE, вместо этого выпуская 100500-ю IDE на базе кривой эклипсы.
YouCompleteMe и taglist.vim вполне делают псевдо-IDE из вима при желании.
В emacs тоже поидее есть clang-autocomplete, ctags и другие плагины для получения IDE из редактора… но все эти плагины некачественные и только замедляют работу, т.к. периодически что-то в них глючит. В итоге из всех автокомплитов я остановился на самом тупом, который дополняет словами из открытых буферов, а по проекту хожу grep'ом…
Не знаю, я и в Нетбинсе своём прекрасно живу десятки минут без единого переключения своих рук к мыши. Немного поднастроил стандартную раскладку горячих клавиш (буквально пару штук), выучил остальные полезные комбинации — и нормально как-то живётся. Вообще, я очень привык ко многим фишкам Нетбинса, и не вижу здесь ничего зазорного: наоборот это показатель того, что ты научился использовать свою IDE на полную мощь.
Это, например, такие функции, как поиск какого-то вхождения по всему проекту, при этом, когда ты находишься на одном из результатов поиска, нажатие Ctrl+< и Ctrl+> переключает тебя между предыдущим и следующим результатами. Особенно это помогает, когда тебе надо прошерстить штук 100 найденных позиций в коде и проанализировать каждую из них. Ну как в такие моменты не полюбить Netbeans?
И это всё — из коробки, удобно настроенное, прекрасно работает. Ну и зачем мне какие-то редакторы с, теоретически, немного более высоким уровнем гибкости? Ради понтов? Я не считаю разумным тратить столько своего времени только ради того, чтобы потом понтоваться своим супер-редактором перед другими людьми. Лучше ведь понтоваться перед ними своими крутыми проектами, как думаете? )
Это, например, такие функции, как поиск какого-то вхождения по всему проекту, при этом, когда ты находишься на одном из результатов поиска, нажатие Ctrl+< и Ctrl+> переключает тебя между предыдущим и следующим результатами. Особенно это помогает, когда тебе надо прошерстить штук 100 найденных позиций в коде и проанализировать каждую из них. Ну как в такие моменты не полюбить Netbeans?
И это всё — из коробки, удобно настроенное, прекрасно работает. Ну и зачем мне какие-то редакторы с, теоретически, немного более высоким уровнем гибкости? Ради понтов? Я не считаю разумным тратить столько своего времени только ради того, чтобы потом понтоваться своим супер-редактором перед другими людьми. Лучше ведь понтоваться перед ними своими крутыми проектами, как думаете? )
Мы в hexlet.io переодически проводим вебинары и один из последних был как раз про vim www.youtube.com/watch?v=79OWQ1qJwto.
Основная идея в том что vim это слепой десятипальцевый способ редактирования текста и его мощь именно в командном режиме. Попытка смотреть на него как на IDE уводит от сути и всегда плагины вима будут недотягивать до автоматизации, которая есть практически в любой иде. Но это вторично по отношению к тому за что его по настоящему любят и пользуются им.
Основная идея в том что vim это слепой десятипальцевый способ редактирования текста и его мощь именно в командном режиме. Попытка смотреть на него как на IDE уводит от сути и всегда плагины вима будут недотягивать до автоматизации, которая есть практически в любой иде. Но это вторично по отношению к тому за что его по настоящему любят и пользуются им.
Программистам платят за программирование, а не редактирование текста. А программирование это:
1. Изучение существующего кода и зависимостей между разными его частями: навигация по цепочкам вызовов буквально с одного конца проекта в совершенно другой.
2. Отладка либо самого приложения, либо падающих тестов: расстановка брейкпоинтов, разглядывание стека вызовов, и прочее.
3. Упорядочивание структуры кода после внесения очередных изменений: начиная с переименования всяких сущностей в коде и заканчивая перекладыванием одних директорий в другие.
4. И да, иногда ещё редактирование текста.
Совершенно не понимаю, почему всех так тянет почти-отождествлять «удобный процесс программирования» и «удобное редактирование текста». Программа — это нифига не текст. Это текст, оформленный очень определённым образом. Глупо не пользоваться этим нюансом.
1. Изучение существующего кода и зависимостей между разными его частями: навигация по цепочкам вызовов буквально с одного конца проекта в совершенно другой.
2. Отладка либо самого приложения, либо падающих тестов: расстановка брейкпоинтов, разглядывание стека вызовов, и прочее.
3. Упорядочивание структуры кода после внесения очередных изменений: начиная с переименования всяких сущностей в коде и заканчивая перекладыванием одних директорий в другие.
4. И да, иногда ещё редактирование текста.
Совершенно не понимаю, почему всех так тянет почти-отождествлять «удобный процесс программирования» и «удобное редактирование текста». Программа — это нифига не текст. Это текст, оформленный очень определённым образом. Глупо не пользоваться этим нюансом.
Так же глупо как отказываться от удобного редактирования текста, а код это всё-таки текст.
Этот холивар очередное скатывание в райности. По мне так все эти вещи (высокоуровненое редактирование — автокомплиты/анализаторы в ide и низкоуровневое — vim) очень хорошо дополняют друг друга.
Этот холивар очередное скатывание в райности. По мне так все эти вещи (высокоуровненое редактирование — автокомплиты/анализаторы в ide и низкоуровневое — vim) очень хорошо дополняют друг друга.
Можете раскрыть тему «низкоуровневого редактирования»?
Непосредственно работа с текстом. Вим позволяет быстро перемещаться/редактировать текст не убирая рук с клавиатуры (причём не уходя на стрелки).
Я предпринимал несколько попыток изучить Vim хотя бы на уровне «просто редактирования текста» — без всяких там плагинов и прочего хардкора. Очень удивило, что все туториалы сводятся к решению задач типа «прыгнуть на 3 слова влево и оказаться на первом символе первого слова» или «прыгнуть на строчку 192». Никогда в жизни у меня не было практической задачи «прыгнуть на 3 слова влево». У меня вообще нет привычки считать слова, поэтому я могу видеть куда мне надо попасть, но я понятия не имею сколько у меня слов от курсора до того места. Я не могу вспомнить ни одного файла, про который смог бы рассказать что там находися на какой-то строчке. Действительно кто-то может это запомнить? С другой стороны я совершенно точно знаю, что до тех пор, пока я _итеративно_ двигаю курсор куда-то в сторону куда мне нужно, и вижу, что он туда движется, в какой-то момент я смогу сделать усилие над собой и остановиться оказавшись в нужном месте.
Вы можете привести какой-то практический пример в контексте программирования, когда «попсовый» подход однозначно проигрывает у Vim? Только чтоб не экзотическая задача, которая возникает раз в год, а какое-то базовое действие, которое нужно повторять по несколько раз в день?
Вы можете привести какой-то практический пример в контексте программирования, когда «попсовый» подход однозначно проигрывает у Vim? Только чтоб не экзотическая задача, которая возникает раз в год, а какое-то базовое действие, которое нужно повторять по несколько раз в день?
Никогда в жизни у меня не было практической задачи «прыгнуть на 3 слова влево»
А задачи замены всего содержимого текущего тега, или значения атрибута тега, или выравнивания тела функции, или может замены текущего слова?
всего содержимого текущего тега, или значения атрибута тега
Универсальное решение для замены куска текста: иду в начало, зажимаю Shift, иду в конец, начинаю писать новое содержимое, старое при этом удаляется. Ходить в начало и в конец можно по-разному — зависит от того сколько в нынешнем содержимом строчек, где именно это содержимое начинается. От банального Home, до Ctrl+Left много раз, до банального челябинского Ctrl+A.
выравнивания тела функции
Есть какая-то кнопка для этого и в Visual Studio и в IDEA. Очень редко ей пользуюсь, т.к. обе среды при написании кода сами расставляют все отступы, а при вставке совершенно левого кода тут же его форматируют.
замены текущего слова
Что-то типа Alt+Shift+Up и начать писать новое слово (в IDEA по крайней мере).
Универсальное решение для замены куска текста
Жмякаете dit, удаляете содержимое тега. Есть еще сочетания для удаления всего между {}, [], <>, "", и т.д.
а при вставке совершенно левого кода тут же его форматируют
Да, прекрасная возможность. К сожалению у меня не всегда оно работало.
Что-то типа Alt+Shift+Up и начать писать новое слово
Слово, предложение, блок обрамленный чем либо и т.д.
Жмякаете dit, удаляете содержимое тега. Есть еще сочетания для удаления всего между {}, [], <>, "", и т.д.
Т.е. замечательно работает для HTML, CSS, C, C++, Java, C#, JavaScript, JSON, XML но вот для Python, JADE и YAML придётся использовать какой-то абсолютно другой подход, потому что там таких явных маркеров начала и конца (тела функции например) просто нет. Возникает небольшое смущение: вроде задача «заменить содержимое блока» есть буквально везде, но решения для этой задачи в Vim будет отличаться для разных языков. Т.е. ваше dit совершенно замечательное, но нифига не универсальное.
Слово, предложение, блок обрамленный чем либо и т.д.
У меня в коде нет предложений. Блоки обрамлённые чем либо тоже не всегда есть — выше привёл примеры.
Т.е. ваше dit совершенно замечательное, но нифига не универсальное
Не, она будет работать хоть в LaTeX, если вы засуните туда теги.
У меня в коде нет предложений
Заменим понятие: предложение — строка
Не, она будет работать хоть в LaTeX, если вы засуните туда теги.
У меня нет опыта с Latex. Покажите пожалуйста как это будет выглядеть для Python — там нет очевидной симметрии у начала и конца блока.
Заменим понятие: предложение — строка
Home, Shift-End, начать что-то писать. Ну или наоборот — End, Shift+Home.
Покажите пожалуйста как это будет выглядеть для Python
Ну тег он и в африке тег. Если вы имеете ввиду блоки, то для Python оно работает на основе отступа, если я не ошибаюсь.
Home, Shift-End, начать что-то писать. Ну или наоборот — End, Shift+Home
Да, я сам раньше удивлялся, как же быстро я нажимаю эти комбинации, пока не перешел на Vim. Там есть комбинация Shift+s, она оказалась побыстрее.
Я тоже не понимаю этих примеров с подсчётом слов и строк.
Тут важно, что вим не делает чего-то такого уникального. Он просто позволяет делать всё удобнее и быстрее.
Удалить слово, удалить всё до конца строки, удалить всё в скобках/кавычках, выделения, перемещение по словам/абзацам. И всё это делается без использования мыши.
Строки у меня сами считаются
Тут важно, что вим не делает чего-то такого уникального. Он просто позволяет делать всё удобнее и быстрее.
Удалить слово, удалить всё до конца строки, удалить всё в скобках/кавычках, выделения, перемещение по словам/абзацам. И всё это делается без использования мыши.
У меня 2 вопроса:
1. Что такое enterprise и почему вы его как-то отделяете от остального программирования?
2. Что такое веб-программисты и почему вы их отделяете от Java/.NET программистов?
Дисклеймер: я уже год в проекте с бэкендом на Java (enterprise?) и фронтэндом на Angular (веб?). Действительно пишу бэкенд в IDEA, а фронтэнд — в редакторе. Ответ на вопрос «почему?» очень простой: потому что я не хочу ломать психику завставляя себя понять, что когда я пишу Java — куча плюшек от IDE есть, а когда JavaScript — про плюшки можно забыть. Типа «видишь Atom — забудь про Alt+Shift+R».
1. Что такое enterprise и почему вы его как-то отделяете от остального программирования?
2. Что такое веб-программисты и почему вы их отделяете от Java/.NET программистов?
Дисклеймер: я уже год в проекте с бэкендом на Java (enterprise?) и фронтэндом на Angular (веб?). Действительно пишу бэкенд в IDEA, а фронтэнд — в редакторе. Ответ на вопрос «почему?» очень простой: потому что я не хочу ломать психику завставляя себя понять, что когда я пишу Java — куча плюшек от IDE есть, а когда JavaScript — про плюшки можно забыть. Типа «видишь Atom — забудь про Alt+Shift+R».
Вот это:
и это:
друг другу очень сильно противоречит. Программисты «подешевле и побольше» — это как раз те, от кого код достался в наследство. Программистов с хорошими скиллами рефакторинга — один на сотню и они совершенно точно «подороже».
Снова удивлюсь и не соглашусь. В чём героизм напрягать мозг на рутину типа «переменная _теперь_ не используется и её можно удалить»? Любая работа, которую может делать компьютер, должна делаться компьютером. Компьютер вполне может за меня построить граф всех зависимостей всех классов/методов в проекте и рассказать мне какие классы или методы нигде не используются.
Нет там никакой специфики — везде одно и то же: есть требования, которые нужно выполнять, есть код, который при этом нужно писать, есть тесты, который тоже нужно писать, чтобы получить минимальную уверенность, что всё работает как нужно. И да, в любой программе на любом ЯП рано или поздно возникает момент, когда понимаешь, что какие-то части реализации нужно переделать, чтобы сделать последующие изменения возможными — и вот здесь полноценная IDE помогает порубить всё налево и направо ничего не сломав, а редактор продолжает по-хипстерски подсвечивать синтаксис какой-нибудь темой Monokai намекая, что раз надел кеды и работаешь из кафешки, придётся всё делать руками.
рефакторить приходится целыми подсистемами, с IDE это проще.
и это:
Программисты там часто берутся из разряда подешевле и побольше
друг другу очень сильно противоречит. Программисты «подешевле и побольше» — это как раз те, от кого код достался в наследство. Программистов с хорошими скиллами рефакторинга — один на сотню и они совершенно точно «подороже».
им нужно поставить IDE которая будет бить их по рукам, и которая не даст сломать процесс, и которая будет заботливо расставлять пропущенные запятые, показывать что вместо = тут должно быть ==, что переменная не используется и т.п…
Снова удивлюсь и не соглашусь. В чём героизм напрягать мозг на рутину типа «переменная _теперь_ не используется и её можно удалить»? Любая работа, которую может делать компьютер, должна делаться компьютером. Компьютер вполне может за меня построить граф всех зависимостей всех классов/методов в проекте и рассказать мне какие классы или методы нигде не используются.
Те кто пишут для веб на PHP, JS, Python, Ruby.
Нет там никакой специфики — везде одно и то же: есть требования, которые нужно выполнять, есть код, который при этом нужно писать, есть тесты, который тоже нужно писать, чтобы получить минимальную уверенность, что всё работает как нужно. И да, в любой программе на любом ЯП рано или поздно возникает момент, когда понимаешь, что какие-то части реализации нужно переделать, чтобы сделать последующие изменения возможными — и вот здесь полноценная IDE помогает порубить всё налево и направо ничего не сломав, а редактор продолжает по-хипстерски подсвечивать синтаксис какой-нибудь темой Monokai намекая, что раз надел кеды и работаешь из кафешки, придётся всё делать руками.
Если уж абстрагировать до такой степени, то давайте сразу и доабстрагиуремся до того, что программирование в конечном счете — это редактирование текста.
Не соглашусь. Программирование — это в первую очередь осознание структуры решения, и только во-вторую — перенос этого осознания в текст. Осознание структуры — это, ИМХО, процентов 90% от всей задачи. Совершенно нормальна ситуация когда 4 часа изучаешь существующий код и тесты к нему, а потом за 20 минут делаешь все нужные правки.
А навскидку — в вебе существует гораздо больший зоопарк технологий, который IDE поддерживать просто не успевают.
Аналогичную мысль я высказывал где-то выше в этом топике — из-за специфики JavaScript нормальная IDE просто невозможна. Та IDE, которая возможна, не будет отличаться от редактора с парой плагинов.
Всякие тесты и CI распространены в гораздо меньшей степени, чем в явамире.
Вы очень неправы — в мире JavaScript есть огромное количество тестовых фреймворков и сопутствующих библиотек на любой вкус и цвет. Есть куча решений для написания тестов в контексте реальной среды исполнения — начиная от Karma, которая гоняет тесты в настоящем броузере и заканчивания Protractor для Angular, который позволяет вообще всё решение полностью запустить, понажимать кнопочки и убедиться, что приложение ведётся себя как ожидается. Про CI не знаю что вы имеете в виду: то что весь опенсорсный JavaScript гоняет тесты на Travis и любит вставлять беджики со статусом билда в README на гитхабе — это факт. А как именно новые билды попадают в репозитории — уже второстепенный вопрос. Обычно либо через тот же Travis, либо какой-то одной командой grunt, которую _при желании_ можно точно так же выполнять через Travis.
Let Mortal Kombat begin.
Вот этой фразы точно не хватает. Есть такая поговорка «О вкусах не спорят», кому удобно работать в интегрированной среде, кому «просто в редакторе», хотя некоторые простые редакторы через расширения становятся как раз уже интегрированной средой разработки.
Вот этой фразы точно не хватает. Есть такая поговорка «О вкусах не спорят», кому удобно работать в интегрированной среде, кому «просто в редакторе», хотя некоторые простые редакторы через расширения становятся как раз уже интегрированной средой разработки.
Проблема в том, что это — не спор о вкусах. Есть люди, которым нравится одно, есть люди, которым нравится другое. И эти группы различаются не только предпочтениями в выборе редактора. У них разная область деятельности, они решают разные задачи. Для одних из этих задач годится один инструмент, для других — другой. Вот, один товарищ выше писал, что ему надо было редактировать файл под 100 мегабайтов и он его смог только в Vim загрузить. При этом сторонники IDE не пытались его переубедить в том, что этот файл откроется где-то еще.
Но как только заходит речь о том, что редакторы слабее и хуже при разработке
Вот оттуда, как мне кажется, и пошел спор. IDE не сделает новичка экспертом. Vim — тем более не сделает. Эксперта отличает умение подбирать инструмент под задачу и спектр владения этими инструментами. Я Vim плохо знаю и терпеть ненавижу за его избыточную сложность и непохожесть на вс на свете. Но если черт меня дернет открыть файл на 100 мегов, открою в нем. Потому что он это делает лучше всех.
Но как только заходит речь о том, что редакторы слабее и хуже при разработке
крупных проектов, большинство их сторонников встают на дыбы и начинают «рыть землю» на предмет «вы просто не умеете ими пользоваться», вместо того, чтобы мирно признать, что их проекты просто меньше, чем те, в которых работают на IDE. Это же удар по самолюбию — вроде как несерьезное дело делаешь…
Вот оттуда, как мне кажется, и пошел спор. IDE не сделает новичка экспертом. Vim — тем более не сделает. Эксперта отличает умение подбирать инструмент под задачу и спектр владения этими инструментами. Я Vim плохо знаю и терпеть ненавижу за его избыточную сложность и непохожесть на вс на свете. Но если черт меня дернет открыть файл на 100 мегов, открою в нем. Потому что он это делает лучше всех.
Эксперта отличает умение подбирать инструмент под задачу и спектр владения этими инструментами
Мне кажется, что это самое правильное из всего сказанного в комментах.
Лично я пользуюсь на данный момент связкой Vim + MSVS (для С++).
Vim, отчасти моя вкусовщина (имеет место быть), но в нем я быстро пишу новый код.
Объяснить могу отчасти тем же автодополнением — дополняются только слова в открытых буферах. Когда я описываю новый класс мне далеко не всегда нужны все определения во всех хедерах. Мне нужен очень сильно ограниченный набор. В MSVS то же самое автодополнение иногда требует набрать имя локальной переменной чуть менее чем полностью, что крайне раздражает.
Когда класс определен — в дело вступает MSVS ибо отладка кода в ней реализована хорошо. И в целом, это меня устраивает, так как решает нужную мне задачу.
Именно поэтому в qtcreator есть режим «FakeVim».
С qtcreator я не знаком, но пытался в какой-то IDE для Python включить режим Vim в редакторе. Все было бы здорово кроме того, что режим работает несколько отлично от настоящего Vim на уровне базовых действий (работа с выделенным текстом и т.д.) что делает этот режим бесполезным. Да и в целом, я сомневаюсь, что кто-то бы стал полностью воспроизводить функционал Vim в IDE.
Ну так пользуйтесь чистым Vim. Он таки вполне расширяется до IDE. Причем даже под виндой.
Но на вашем месте я все таки бы глянул свежий qtcreator, может и понравится.
Раздел документации про режим FakeVim
Но на вашем месте я все таки бы глянул свежий qtcreator, может и понравится.
Раздел документации про режим FakeVim
Ну так пользуйтесь чистым Vim. Он таки вполне расширяется до IDE.
Насколько расширяем Vim, я знаю. Даже плагин к нему написал в борьбе за чистоту форматирования кода.
MSVS я сейчас пользуюсь по простой причине — я не единственный человек в команде и весь проект написан в ней. К тому же, в ней есть очень крутая фича Parallel Stacks для отладки многопоточного кода.
QtCreator при первой же возможности попробую.
Не смотрели VsVim? VIM эмулирован достаточно полно.
вместо того, чтобы мирно признать, что их проекты просто меньше, чем те, в которых работают на IDE. Это же удар по самолюбию — вроде как несерьезное дело делаешь…
CPython — почти миллион строк кода и 25 лет разработки. Это достаточно большой проект? Однако же Гвидо всё ещё пишет его в Vim/Emacs и недолюбливает Eclipse.
Мне кажется, тут дело именно в CPython.
C — это набор функций и много глобальных переменных. Я утрирую, но всё-таки. Здесь нет областей видимости и других прелестей ООП, поэтому IDE не раскроет себя на 100%.
Да твит довольно двусмысленный, и очень хорошо перекликается со статьёй.
C — это набор функций и много глобальных переменных. Я утрирую, но всё-таки. Здесь нет областей видимости и других прелестей ООП, поэтому IDE не раскроет себя на 100%.
Да твит довольно двусмысленный, и очень хорошо перекликается со статьёй.
А каким боком области видимости влияют на возможности IDE? Проанализировать include-ы ничуть не сложнее, чем проанализировать import-ы, а C — синтаксически достаточно простой язык, в разы проще той же Scala, например.
Так или иначе, это только один из примеров одного известного человека. А есть целые сообщества и даже компании, которые уходят с тяжеловесных IDE на что-то более простое и кастомизируемое. Например, посмотрите на Atom от GitHub-а — они его явно не от безделия создали. Или на сообщество языка Julia, где главный рекоммендуемый редактор — Juno — построен на LightTable. Ну или на R, где основная альтернатива — это либо Emacs+ESS, либо RStudio, которая тоже мало чем отличаетя от блокнота со встроенным REPL-ом. Примеров — сотни.
Так или иначе, это только один из примеров одного известного человека. А есть целые сообщества и даже компании, которые уходят с тяжеловесных IDE на что-то более простое и кастомизируемое. Например, посмотрите на Atom от GitHub-а — они его явно не от безделия создали. Или на сообщество языка Julia, где главный рекоммендуемый редактор — Juno — построен на LightTable. Ну или на R, где основная альтернатива — это либо Emacs+ESS, либо RStudio, которая тоже мало чем отличаетя от блокнота со встроенным REPL-ом. Примеров — сотни.
Дело не способностях IDE, а в удобстве использования того, что она может предложить в этом случае. Скажем, выдаст она в автодополнении 1000 вариантов названий функций. Это не сильно будет отличаться от того, что может предложить редактор.
RStudio — это такая вполне себе IDE)
А вот Emacs + ESS я что-то так и не понял зачем оно надо…
А вот Emacs + ESS я что-то так и не понял зачем оно надо…
Так а что в ней есть от «настоящих IDE»? ) Вроде адских инструментов для рефакторинга нет? Визуализация графиков? Так она и в чистой консоли есть. Дебаггер? Ну может быть, но вроде как REPL его вполне неплохо заменяет.
Чисто из интереса, а чего вам в Emacs + ESS не хватает, что есть, например, в той же RStudio?
Чисто из интереса, а чего вам в Emacs + ESS не хватает, что есть, например, в той же RStudio?
Мне сложно представить себе проект на R, де потребуется сложный рефакторинг) Ну дебагер есть, редактор есть, плюс всякие удобности типа вывода графиков и т.п… чем не IDE)
Может я как-то не так настраивал ESS, но я не понял, чем он вообще отличается от консольного интерфейса R)
Может я как-то не так настраивал ESS, но я не понял, чем он вообще отличается от консольного интерфейса R)
Так вот в ESS практически всё то же самое — редактор с подсветкой синтаксиса и автодополнением, выполнение произвольных комманд, в т.ч. и для показа графиков (в отдельном окне, правда, но, я думаю, это можно пережить :)), даже дебаггер вроде как есть (хотя я сам им не пользовался, так что про качество ничего не скажу). Так что тоже вполне себе IDE!
del
Например, низкоуровневая разработка для linux.
Не про Linux, но под контроллеры, в т.ч. Baremetal, использую Qt Creator. Проект около 40k чистых строк кода на C++. Да и вообще использую для всякой мелочи, удобно. Программки на пробу пишу где душа ляжет: mcedit, gedit, а то и просто на ideone :-)
Немного в защиту EMACS:
— не надо запоминать все эти комбинации, когда есть пакет ergoemacs-mode (рекомендую ставить из MELPA STABLE, в MELPA версия с глюками), который даёт старые добрые Ctrl+C, Ctrl+V и т.д.
— для запоминания клавиш можно распечатать небольшой лист формата A3 и повесить на стену, как я и сделал. Уверен, тем, кто работает в IDE, тоже может пригодиться такая штука.
— переход к определению методов, функций и классов можно сделать быстрым по Ctrl+. когда установлены нужные плагины. Для Python использую anaconda-mode, всем доволен. Есть такая же штука для JS — tern-mode, js2-mode.
— подсказки можно сделать с помощью company-mode (COMPlete ANYthere). Безусловно, развёрнутую документацию как в IDE в подсказке не всегда можно получить, но скажите, Вы правда пользуетесь встроенной справкой а не гуглом?
— не надо запоминать все эти комбинации, когда есть пакет ergoemacs-mode (рекомендую ставить из MELPA STABLE, в MELPA версия с глюками), который даёт старые добрые Ctrl+C, Ctrl+V и т.д.
— для запоминания клавиш можно распечатать небольшой лист формата A3 и повесить на стену, как я и сделал. Уверен, тем, кто работает в IDE, тоже может пригодиться такая штука.
— переход к определению методов, функций и классов можно сделать быстрым по Ctrl+. когда установлены нужные плагины. Для Python использую anaconda-mode, всем доволен. Есть такая же штука для JS — tern-mode, js2-mode.
— подсказки можно сделать с помощью company-mode (COMPlete ANYthere). Безусловно, развёрнутую документацию как в IDE в подсказке не всегда можно получить, но скажите, Вы правда пользуетесь встроенной справкой а не гуглом?
О, а ergoemacs так можно устанавливать? Спасибо, не знал.
С официальным сайтом ergo у меня как-то не очень сложилось, хотя пару кусков из конфига себе забрал.
С официальным сайтом ergo у меня как-то не очень сложилось, хотя пару кусков из конфига себе забрал.
— не надо запоминать все эти комбинации, когда есть пакет ergoemacs-mode (рекомендую ставить из MELPA STABLE, в MELPA версия с глюками), который даёт старые добрые Ctrl+C, Ctrl+V и т.д.
Можно даже проще:
(cua-mode)
Вроде во всех современных Emacs-ах он встроенный, надо только добавить в .init.el
И если размер проекта приближается к 100 тыс строк и состоит из тысяч файлов...
Я не первый десяток лет профессионально занимаюсь программированием, сделал немало, но до сих пор не могу себе представить проект из нескольких тысяч файлов. Судя по комментариям на разных ветках, разных форумах такое встречается чуть не на каждом шагу, но я все равно не могу себе это представить, Какой должна быть задача, какой объем функций, чтобы потребовался такой монстр? И почему нельзя разбить его на связанные, но независимые субпроекты, каждый из которых вести отдельно?
Текущий проект, на котором я работаю, состоит из 1368 файлов PHP и 109315 строк (непустых, без комментариев). Плюс библиотек (не стандартных) — 1962 файлов и 59843 строк. Плюс к этому всякие xml, css, html, js и т.п.
Предыдущий — тех же объемов. Порядка 1500 файлов и 98000 строк, а библиотеки даже не считал.
Оба проекта B2B, разные корпоративные функции со всеми вытекающими — пользователи, отчёты, админки с разными справочниками и т.п. Плюс много взаимодействий со внешними сервисами через soap, rest и всякие самописные протоколы.
Разбить код на несколько — можно, наверное. Библиотеки и разбиты. Но работает это всё равно всё вместе. И дорабатывать/исправлять надо вместе. Разделить вообще на несколько проектов для пользователей — не вариант.
Предыдущий — тех же объемов. Порядка 1500 файлов и 98000 строк, а библиотеки даже не считал.
Оба проекта B2B, разные корпоративные функции со всеми вытекающими — пользователи, отчёты, админки с разными справочниками и т.п. Плюс много взаимодействий со внешними сервисами через soap, rest и всякие самописные протоколы.
Разбить код на несколько — можно, наверное. Библиотеки и разбиты. Но работает это всё равно всё вместе. И дорабатывать/исправлять надо вместе. Разделить вообще на несколько проектов для пользователей — не вариант.
Хм… Может, это специфика web-проектов. Ничего крупного в этой области я не делал — так, всякие мелочи, чтобы попробовать на зуб — поэтому не возьму на себя смелости давать оценки в этой области.
Самый крупный проект, с которым я имел дело — разработка компилятора с реально большой run-time библиотекой и набором утилит( скорее это можно назвать средой программирования ) ~640 файлов исходников ( c и prg ), из них ~230 — языковые ( сообщения на разных языках и кодовые страницы ). Здесь использование IDE исключалось уже потому, что этот продукт строится на разных ОС и поддерживает несколько разных С компиляторов.
Или, например, бухгалтерский и управленческий учет среднего ( ~1000 человек ) предприятия — ~180 файлов, но этот проект разбит на десяток субпроектов, связанных между собой, но разрабатываемых и компилируемых отдельно.
Самый крупный проект, с которым я имел дело — разработка компилятора с реально большой run-time библиотекой и набором утилит( скорее это можно назвать средой программирования ) ~640 файлов исходников ( c и prg ), из них ~230 — языковые ( сообщения на разных языках и кодовые страницы ). Здесь использование IDE исключалось уже потому, что этот продукт строится на разных ОС и поддерживает несколько разных С компиляторов.
Или, например, бухгалтерский и управленческий учет среднего ( ~1000 человек ) предприятия — ~180 файлов, но этот проект разбит на десяток субпроектов, связанных между собой, но разрабатываемых и компилируемых отдельно.
>Здесь использование IDE исключалось уже потому, что этот продукт строится на разных ОС и поддерживает несколько разных С компиляторов
И таки почему исключается IDE?
И таки почему исключается IDE?
А какое IDE вы предлагаете использовать, чтобы строить с его помощью проект на Windows, разных Unix, Linux, MacOs, Os/2, Android и чтобы поддерживались gcc, Borland C, Mingw, mvc, Watcom, Pelles C и пр.? К тому же ~110 файлов из упомянутых ~640 — prg и компилятор для них — тот самый, который строится.
QtCreator в связке с cmake'ом… не?
Но мне, для удобства, пришлось допилить CMake плагин. PPA: launchpad.net/~adrozdoff/+archive/ubuntu/qtcreator-git Ща используется CMake для baremetal с кросс-компилятором.
Ну, ось проблемой как мне кажется точно быть не может, сейчас все IDE позволяют работать над проектами под любую платформу. OS/2 может быть какой-то проблемой (ни разу с ней дела не имел — не знаю), но вот все остальные проблемой быть не должны.
С компилятором честно говоря тоже не понял — в той же Идее можно указать каким компилятором пользоваться и вообще сделать n настроек запуска/сборки под каждый компилятор и/или его отдельную версию.
Либо я не до конца понимаю задумку.
С компилятором честно говоря тоже не понял — в той же Идее можно указать каким компилятором пользоваться и вообще сделать n настроек запуска/сборки под каждый компилятор и/или его отдельную версию.
Либо я не до конца понимаю задумку.
Eclipse + GCC + Make. Под Windows это всё тоже есть. Вот как я себе окружение настраиваю: bigfatbrowncat.github.io/cross-building
А расскажите, что именно из себя представляют эти проекты? Это обычный веб (грубо говоря, сайты) или что-то более хитрое?
Проект на Scala, над которым мы работаем последние месяца 4, содержит всего 360 файлов и 17729 строк. Spark Core — проект, мягко говоря, не маленький — 759 файлов и 90906 строк. Самый известный в Java менеджер зависимостей — Maven — имеет 1553 файла (из которых 413 — XML) и 101942 строк. Правда, если посмотреть, например, на CPython, то там мы видим 2736 файлов и 964228 строк, но так и проекту уже скоро четверть века.
Поэтому информация о сути ваших проектов и их длительности была бы очень полезна.
Проект на Scala, над которым мы работаем последние месяца 4, содержит всего 360 файлов и 17729 строк. Spark Core — проект, мягко говоря, не маленький — 759 файлов и 90906 строк. Самый известный в Java менеджер зависимостей — Maven — имеет 1553 файла (из которых 413 — XML) и 101942 строк. Правда, если посмотреть, например, на CPython, то там мы видим 2736 файлов и 964228 строк, но так и проекту уже скоро четверть века.
Поэтому информация о сути ваших проектов и их длительности была бы очень полезна.
Продолжая список интересных фактов: старичёк GNU Emacs имеет в себе 2324 файло и 1455440 строк :)
Деталей разглашать не могу, извините.
Оба на php + фреймворк. В одном случае Symfony, в другом — самописные.
По сути оба — да сайты. Суть простая — создание и управление заказами. Но заказы состоят из мнножества различных сущностей, для которых нужны редактируемые справочники. Плюс всё это обрастает кучей бизнес-правил для разграничения доступа пользователей, для расчёта различных наценок/комиссий/курсов, для формирования отчётов. Нужны гибкие политики для обслуживания всего этого дела, и опять же админка. Множество усилий тратится на валидацию пользовательского ввода.
Например, чем недавно занимался — компании может предоставляться скидка в зависимости от некоторых условий. Скидка разная. Нужно уже 2 сущности doctrine — для хранения скидок и условий (можно и в 1-й но будет дублирование). Сами сущности (200 строк) + админки для них на sonata (154 строки). Это без комментариев и пробелов, хотя это не совсем корректно — в symfony аннотации играют большую роль. Но пусть так. Дальше — простенький сервис для их получения — 50 строк. Расчётчик + пара интерфейсов для работы с несколькими поставщиками — 68 строк. Использование всего этого — ещё около 20 строк. Это пока ещё бекенд. На фронте ещё порядка 10 строк на php, и куски на html и js.
Итого на не очень сложную фичу — 500 строк. Сущностей порядка 300. Даже только ими, без логики, проект вырастает до 50-60 тыс строк только на php.
Как-то так.
Оба на php + фреймворк. В одном случае Symfony, в другом — самописные.
По сути оба — да сайты. Суть простая — создание и управление заказами. Но заказы состоят из мнножества различных сущностей, для которых нужны редактируемые справочники. Плюс всё это обрастает кучей бизнес-правил для разграничения доступа пользователей, для расчёта различных наценок/комиссий/курсов, для формирования отчётов. Нужны гибкие политики для обслуживания всего этого дела, и опять же админка. Множество усилий тратится на валидацию пользовательского ввода.
Например, чем недавно занимался — компании может предоставляться скидка в зависимости от некоторых условий. Скидка разная. Нужно уже 2 сущности doctrine — для хранения скидок и условий (можно и в 1-й но будет дублирование). Сами сущности (200 строк) + админки для них на sonata (154 строки). Это без комментариев и пробелов, хотя это не совсем корректно — в symfony аннотации играют большую роль. Но пусть так. Дальше — простенький сервис для их получения — 50 строк. Расчётчик + пара интерфейсов для работы с несколькими поставщиками — 68 строк. Использование всего этого — ещё около 20 строк. Это пока ещё бекенд. На фронте ещё порядка 10 строк на php, и куски на html и js.
Итого на не очень сложную фичу — 500 строк. Сущностей порядка 300. Даже только ими, без логики, проект вырастает до 50-60 тыс строк только на php.
Как-то так.
Проект на Scala, над которым мы работаем последние месяца 4, содержит всего 360 файлов и 17729 строк.Подозреваю, что на Java это проект занимал бы раз в 5 больше…
Откройте для себя Spring Framework, например: projects.spring.io/spring-framework
А я, к примеру, участвовал в разработке проекта, который на Spring-е был написан и сам по себе был не меньше.
Или, скажем, скачайте исходник самой IntelliJ Idea. И поглядите внутрь. Там поскромнее, но тоже увесисто классов.
Хотите другого, блолее низкого уровня — вытащите Android. Там тоже кода ой, как прилично.
Отдельно? Можно. Так и делают обычно. Но собирается всё вместе и по коду прыгать/разбираться приходится «насквозь». Помню, как я мучился, будучи неспособным весь libcore и Android Framework загрузить в Eclipse одновременно — памяти было всего 1,5 гига — комп старый… И вспоминать не хочется.
А я, к примеру, участвовал в разработке проекта, который на Spring-е был написан и сам по себе был не меньше.
Или, скажем, скачайте исходник самой IntelliJ Idea. И поглядите внутрь. Там поскромнее, но тоже увесисто классов.
Хотите другого, блолее низкого уровня — вытащите Android. Там тоже кода ой, как прилично.
Отдельно? Можно. Так и делают обычно. Но собирается всё вместе и по коду прыгать/разбираться приходится «насквозь». Помню, как я мучился, будучи неспособным весь libcore и Android Framework загрузить в Eclipse одновременно — памяти было всего 1,5 гига — комп старый… И вспоминать не хочется.
Текстовые редакторы объективно чуть лучше подходят для нестандартных задач и сред.
Например, у меня на работе разработка ведётся на удалённом linux-сервере специфической конфигурации без графической среды. Язык — C++. Некоторые коллеги используют NetBeans, т.к. в нём достаточно просто настраивается удалённый билд. При этом навигация по коду работает для объектов в рамках подпроекта, по системным хедерам он в такой конфигурации из коробки прыгать не умеет. Т.е. может и умеет, но мало кто осилил это настроить.
Многие поднимают sshfs и редактируют файлы любимым редактором (ибо от IDE уже толку немного — на локалке нет нужных хедеров, особенно если локалка — MacBook), а собирают проект удалённо из консоли.
Я захожу на сервер по ssh, у меня там месяцами живёт сессия tmux + инстанс emacs. При этом довольно забавно смотреть, как у коллег в их C++-IDE поддержка того же Python нулевая (в некоторых подпроектах есть биндинги к Python), плагина в репозитории, увы, нет. Emacs всеяден, довольно сносно поддерживает множество языков.
Возможность написания плагинов не такая эфемерная, как многим кажется.
У нас, к примеру, нестандартная вики-разметка. Вот так вот сложилось. Потребовалось совсем немного времени, чтобы запилить конвертер org-mode в разметку, а потом написать major-mode для редактирования разметки.
Ещё есть специальный shell, который выполняет команды на группах хостов в кластере. Несколько часов с доками по
Emacs — отличная IDE. Для разработки на Emacs Lisp :) Переходы к определению функции, автодополнение, просмотр документации — всё это отлично работает, пока вы пишите на lisp. С другими языками, как правило, придётся потрудиться. Однако, есть несколько невероятно крутых и удобных языковых плагинов для Emacs, и заметна тенденция увеличения их числа:
Вообще говоря, заметно общее увеличение активности Emacs-сообщества. Надеюсь, нас ждёт ещё много отличных плагинов, и когда-нибудь разработка на C++/Java в Emacs будет действительно приятной.
Например, у меня на работе разработка ведётся на удалённом linux-сервере специфической конфигурации без графической среды. Язык — C++. Некоторые коллеги используют NetBeans, т.к. в нём достаточно просто настраивается удалённый билд. При этом навигация по коду работает для объектов в рамках подпроекта, по системным хедерам он в такой конфигурации из коробки прыгать не умеет. Т.е. может и умеет, но мало кто осилил это настроить.
Многие поднимают sshfs и редактируют файлы любимым редактором (ибо от IDE уже толку немного — на локалке нет нужных хедеров, особенно если локалка — MacBook), а собирают проект удалённо из консоли.
Я захожу на сервер по ssh, у меня там месяцами живёт сессия tmux + инстанс emacs. При этом довольно забавно смотреть, как у коллег в их C++-IDE поддержка того же Python нулевая (в некоторых подпроектах есть биндинги к Python), плагина в репозитории, увы, нет. Emacs всеяден, довольно сносно поддерживает множество языков.
Возможность написания плагинов не такая эфемерная, как многим кажется.
У нас, к примеру, нестандартная вики-разметка. Вот так вот сложилось. Потребовалось совсем немного времени, чтобы запилить конвертер org-mode в разметку, а потом написать major-mode для редактирования разметки.
Ещё есть специальный shell, который выполняет команды на группах хостов в кластере. Несколько часов с доками по
comint — и я могу выполнять команды прямо из любимого редактора с гораздо большим удобством, чем работая из терминала. Более того, легко делиться наработками с коллегами — им нужно лишь вставить код в буфер и выполнить одну команду. Для автоматических обновления приватных плагинов нужно, конечно, настраивать свой плагин-сервер.Emacs — отличная IDE. Для разработки на Emacs Lisp :) Переходы к определению функции, автодополнение, просмотр документации — всё это отлично работает, пока вы пишите на lisp. С другими языками, как правило, придётся потрудиться. Однако, есть несколько невероятно крутых и удобных языковых плагинов для Emacs, и заметна тенденция увеличения их числа:
- Весьма впечатлил tuareg-mode для работы с OCaml. Хотел бы я, чтобы C++ было редактировать так же удобно...
- Я не программирую на Elixir, но Alchemist впечатляет.
- idris-mode тоже выглядит весьма развитым
Вообще говоря, заметно общее увеличение активности Emacs-сообщества. Надеюсь, нас ждёт ещё много отличных плагинов, и когда-нибудь разработка на C++/Java в Emacs будет действительно приятной.
Я захожу на сервер по ssh, у меня там месяцами живёт сессия tmux + инстанс emacs
Хм, в emacs есть tramp-mode, через который можно на удаленные машины по томуже ssh ходить аки тонкий клиент… в чем смысл запускать emacs на удаленной машине?
Вообще говоря, заметно общее увеличение активности Emacs-сообщества. Надеюсь, нас ждёт ещё много отличных плагинов, и когда-нибудь разработка на C++/Java в Emacs будет действительно приятной.
Для начала неплохо бы добавить полноценную многопоточнсть в emacs… без неё ни о каких полноценных intellisense говорить не приходится)
Могу сказать за себя: всё зависит от последовательности действий — обычно я просто лезу на удалённый сервер, изучаю содержимое файловой системы, запускаю какие-то команды, и только когда нужно отредактировать какой-то файл, не переключаясь из окна SSH, открываю файл удалённым Emacs-ом прямо на сервере и делаю нужные правки. А потом продолжаю работать в консоли, и так по кругу.
Хм, в emacs есть tramp-mode, через который можно на удаленные машины по томуже ssh ходить аки тонкий клиент… в чем смысл запускать emacs на удаленной машине?
Я пробовал работать через tramp-mode, но для полноценной разработки он мне не очень понравился.
Во-первых, есть определённая задержка в отклике, больше, чем у терминала.
Во-вторых, у меня как-то не очень получилось подружить clang-format с tramp-mode.
В-третьих, tmux на удалённой машине позволяет держать инстанс Emacs открытым очень долго, переживать рестарты и выключения локальной машины. Сервер выключается гораздо реже, чем дев-машина.
Ну, впринципе если есть возможность свой конфиг утащить на удаленную машину, то может быть консольный emacs и вариант.
Лично у меня с tramp проблем никаких не возникало.
Лично у меня с tramp проблем никаких не возникало.
если есть возможность свой конфиг утащить на удаленную машину
У меня все конфиги на GitHub, устанавливаются на любую машину в один
make install. Пути к программам и прочая мелочь донастраивается через M-x customize в отдельный файл (попадающий в .gitignore) по мере необходимости.Ну, у меня бывала нужда ходить на железку, у которой не было доступа в интернет, т.ч. варианты с выкачиванием из чего-то из большой сети отпадали. Tramp тогда сильно выручал.
з.ы. а может поделитесь ссылкой на свой конфиг? Похоже, что вы тоже разрабатываете под C/C++, может чего интересного у вас там есть под эти языки)
з.ы. а может поделитесь ссылкой на свой конфиг? Похоже, что вы тоже разрабатываете под C/C++, может чего интересного у вас там есть под эти языки)
может чего интересного у вас там есть под эти языки
Да не то чтобы прям что-то интересное было, допил минимален. Пытаюсь больше стандартными средствами обходиться. Мне важен indentation и M-x compile, всё остальное делают плагины и сторонние утилиты.
github.com/roman-kashitsyn/dot-files/tree/master/.emacs.d
Для начала неплохо бы добавить полноценную многопоточнсть в emacs… без неё ни о каких полноценных intellisense говорить не приходится)
Эта проблема давно решается запуском многопоточного бэкэнд-процесса, асинхронно выполняющего все медленные операции. Можно воспринимать Emacs как GUI-thread, все операции с буферами и текстом должны выполняться в одном потоке. Хочется асинхронных воркеров — поднимай подпроцессы, настраивай message-passing.
В Vim, например, даже c этим есть проблемы — нельзя породить подпроцесс и асинхронно с ним общаться. Так что в Emacs ещё всё относительно неплохо.
Эта проблема давно решается запуском многопоточного бэкэнд-процесса, асинхронно выполняющего все медленные операции.
И несмотря на это, в emacs до сих пор простейшие операции, типа комментирвоания пары сотен строк кода, подвешивают редактор)
простейшие операции, типа комментирвоания пары сотен строк кода, подвешивают редактор
Честно говоря, это странно, уж слишком смешные объёмы текста. Возможно, font-lock правила были криво написаны и медленно перекрашивали буфер. Или был включен Semantic — он обычно сильно тормозит, я его отключаю.
Да и врядли тут многопоточность сильно поможет — редактировать буфер в UI всё равно должен один поток. Помочь скорее может более оптимальная виртуальная машина. Возможно, когда нибудь Emacs переведут на Guile vm, должен быть неплохой буст производительности.
Я как-то курочил SQL-файл на пару десятков тысяч строк макросами, особых тормозов не замечал.
Ну, быть может строк было чутка побольше, чем пара сотен, но факт, что ST с этой задачей справлялся без запинок. Semantic я даже не включаю, т.к. он впринципе какой-то глючный, или я не умею его готовить.
А по файлам >500mb даже тупо навигация еле еле шевелится(
А по файлам >500mb даже тупо навигация еле еле шевелится(
факт, что ST с этой задачей справлялся без запинок
Так у ST всё ядро на C++ написано, а в емаксе почти всё, что за гранью примитивных операций (в т.ч. то, что относится к работе с комментариями и подстветкой) — интерпретируемый лисп и регулярки. Повторюсь, многопоточность тут почти наверняка не выход, нужно ускорять ядро.
Эту статью, например, я пишу в Emacs.Вы уж простите, но лучше бы писали в более простом текстовом редакторе, но с проверкой орфографии. Хорошая статья, но всё впечатление портят многочисленные ошибки.
Пользуйтесь своим же главным посылом: инструмент должен соответствовать задаче.
Сам недавно испытывал подобные муки выбора, перебрал множество разных редакторов и IDE, в итоге, остановил свой выбор на Sublime Text 3 (немало пришлось повозиться и настраивать) и Netbeans для разработки на PHP, а для работы с JavaScript когда то купил WebStorm.
Хотел бы купить PhpStorm но для меня это пока дороговато.
Также ранее вместо Sublime Text использовал (в WIndows) Notepad++, хотя и сейчас его тоже иногда использую когда надо быстро поправить одиночные файлы с кодом.
P.S. Т.к. я часто работаю и в Linux, то в нём, я обычно для разработки использую gedit и Netbeans.
Хотел бы купить PhpStorm но для меня это пока дороговато.
Также ранее вместо Sublime Text использовал (в WIndows) Notepad++, хотя и сейчас его тоже иногда использую когда надо быстро поправить одиночные файлы с кодом.
P.S. Т.к. я часто работаю и в Linux, то в нём, я обычно для разработки использую gedit и Netbeans.
Мне кажется, что в рассуждениях IDE vs текстовый редактор есть доля лукавства. Я практически не встречал людей, которые в профессиональной разработке пользуются только текстовым редактором. Все случаи использования Vim и Emacs в повседневной работе заключаются в том, чтобы взять эти инструменты и превратить их в IDE.
Например, мне для более менее комфортной работы (Emacs) требуется 23 плагина:
(depends-on «nlinum»)
(depends-on «which-key»)
(depends-on «powerline»)
(depends-on «projectile»)
(depends-on «auto-complete»)
(depends-on «highlight-symbol»)
(depends-on «magit»)
(depends-on «yasnippet»)
(depends-on «helm»)
(depends-on «helm-projectile»)
(depends-on «helm-ag»)
(depends-on «virtualenvwrapper»)
(depends-on «anaconda-mode»)
(depends-on «ac-anaconda»)
(depends-on «flycheck»)
(depends-on «web-mode»)
(depends-on «emmet-mode»)
(depends-on «json-mode»)
(depends-on «js2-mode»)
(depends-on «ac-js2»)
(depends-on «coffee-mode»)
(depends-on «tern»)
(depends-on «tern-auto-complete»)
Так что, наверное, можно признать, что подавляющему большинству программистов нужна именно IDE (с теми или иными возможностями). Разница заключается в том, что из Vim или Emacs IDE нужно делать самому. А здесь основная мотивация — это очень интересно! И как бонус, в случае ошибок почти всегда есть возможность посмотреть, что происходит внутри и связаться с авторами того или иного плагина (например, автор Tern отвечает достаточно оперативно).
В общем, если вы в детстве ломали игрушки, чтобы посмотреть, что у них внутри, то, скорее всего, вы уже используете Vim или Emacs :)
Кстати, мое мнение — Emacs ну никак не текстовый редактор, это скорее виртуальная машина с языком Emacs Lisp на борту.
Например, мне для более менее комфортной работы (Emacs) требуется 23 плагина:
(depends-on «nlinum»)
(depends-on «which-key»)
(depends-on «powerline»)
(depends-on «projectile»)
(depends-on «auto-complete»)
(depends-on «highlight-symbol»)
(depends-on «magit»)
(depends-on «yasnippet»)
(depends-on «helm»)
(depends-on «helm-projectile»)
(depends-on «helm-ag»)
(depends-on «virtualenvwrapper»)
(depends-on «anaconda-mode»)
(depends-on «ac-anaconda»)
(depends-on «flycheck»)
(depends-on «web-mode»)
(depends-on «emmet-mode»)
(depends-on «json-mode»)
(depends-on «js2-mode»)
(depends-on «ac-js2»)
(depends-on «coffee-mode»)
(depends-on «tern»)
(depends-on «tern-auto-complete»)
Так что, наверное, можно признать, что подавляющему большинству программистов нужна именно IDE (с теми или иными возможностями). Разница заключается в том, что из Vim или Emacs IDE нужно делать самому. А здесь основная мотивация — это очень интересно! И как бонус, в случае ошибок почти всегда есть возможность посмотреть, что происходит внутри и связаться с авторами того или иного плагина (например, автор Tern отвечает достаточно оперативно).
В общем, если вы в детстве ломали игрушки, чтобы посмотреть, что у них внутри, то, скорее всего, вы уже используете Vim или Emacs :)
Кстати, мое мнение — Emacs ну никак не текстовый редактор, это скорее виртуальная машина с языком Emacs Lisp на борту.
Объясните, пожалуйста, что такое helm? Я внятного описания не могу найти.
В моем понимании это штука для быстрого поиска «всего и вся» (условно). Как фильтр из множества доступных вариантов (например, при поиске файла, функции Elisp, буфера и т.д.). Раньше называлась anything. Здесь кратко описывается как “über-extensible spotlight for emacs” или “QuickSilver for emacs”. Имеет интеграцию со сторонними плагинами — silversearcher, projectile и еще много с чем. На MELPA можно посмотреть в результатах поиска по строке «helm».
Видимо я в детстве сломал слишком много игрушек — не тянет меня к конструкторам. А по плагинам — часть плагинов той же IDEA вполне можно поисследовать (те, которые входят в бесплатную версию), те что не входят — по ним всегда можно тикеток отправить разработчикам…
Всем любителям редактирования текста могу сказать одно: JetBrains MPS.
И здесь ему редактор не может помочь абсолютно ничем.Это неправда. Всё сильно зависит от языка программирования и установленных плагинов. Например, для яыка Go и плагина vim-go:
Список параметров метода во всплывающей подсказке не покажет,Покажет. Либо вызываем
:GoInfo когда курсор на нужном слове, либо включаем в настройках let g:go_auto_type_info = 1 и подсказка выводится постоянно по мере перемещения курсора.перейти к определению метода не позволит,Позволит. Штатная команда Vim:
gd (goto definition).синтаксис не проконтролирует.Проконтролирует. При каждой записи файла выполняется проверка синтаксиса, выводится список найденных ошибок и курсор прыгает на первую ошибку.
А где подсказка-то со списком параметров метода?
Внизу.
Она находится вне локуса внимания, то есть интерфейс не человеко-ориентированный.
А, ну тогда да, конечно, только IDE! Раз вне локуса…
Именно.
Если же хочется жратьгов кактус — на здоровье :) Выбор каждого.
Если же хочется жрать
Простым языком звучит так: дергать глаза всё время в низ экрана (а экран может быть 25 дюймов, например), а потом обратно — глазные мышцы сведет.
То есть дергать руки с клавы мышь или изгибать пальцы веером для сочетаний вида Ctrl+Alt+Up это как бы норм, а глазные мышцы, эт слишком, да?
Дело вовсе не в мышцах, а в том, как работает сознание.
Я использую сочетания клавиш тогда и только тогда, когда это приводит к заметному росту производительности. Вот, недавно, например, сидел в отладчике долго и запомнил, что там F6 — step over, а F7 — step in. Или наоборот… забыл уже, в следующий раз погляжу.
А автодополнение вызывается «Ctrl+Space» и используется процентов 60 времени, которое я пишу код. И если я буду зенками вращать вверх-вниз по пять раз за набор строчки, у меня морская болезнь начнется.
А автодополнение вызывается «Ctrl+Space» и используется процентов 60 времени, которое я пишу код. И если я буду зенками вращать вверх-вниз по пять раз за набор строчки, у меня морская болезнь начнется.
Я использую сочетания клавиш тогда и только тогда, когда это приводит к заметному росту производительности
Не знаю таких сочетаний клавишь, который приводили прямо таки к заметному росту производительности. Все они немного увеличивают скорость, но если их много, то и производительность возрастает заметно.
И если я буду зенками вращать вверх-вниз по пять раз за набор строчки, у меня морская болезнь начнется
Вращать не нужно, у вас же монитор не метровый ))
Мдэ. Раскина по ходу народ не читал. Окей, чо.
Я могу ошибаться, но мне кажется, что для того, чтобы понять удобный ли это инструмент или нет, не нужно читать книг.
Согласен. Мне вот даже этим инструментом и пользоваться не пришлось, чтобы понять.
Ну… это — выбор каждого. Кто-то книги читает, а кто-то испытывает на себе. Я вот в детстве почитал немного про то, как наркотики влияют на организм, оценил все плюсы и минусы и с тех пор искренне не понимаю фразу «хотелось попробовать», которой объясняют начало наркотической зависимости многие люди. Хотя это уже оффтоп. Простите.
Этот оффтоп уже из области философии. Практика она все таки имеет больший приоритет, нежели теория.
Проблема в том, что большинство людей, увы, за всю жизнь не догадаются до кучи полезных вещей, которые не очевидны, пока в них человека носом не ткнуть. И эргономика — как раз из их числа. Так что ваша личная практика мало стоит по сравнению с теорией, основанной на научном исследовании общечеловеческой психологии. В ней тоже есть научные закономерности, поверьте.
На предыдущем скриншоте, кстати, пример всплывающей подсказки при автодополнении. Там показаны переменные (Stdin, etc.), но при автодополнении имён функций там же показываются не только имена, но и полностью сигнатуры этих функций.
Вот результат набора
fmt.P<Tab>Что, если параметров в функции четыре?
Это уже получше смотрится. Теперь оно немного похоже на текстовый Eclipse :)
Выглядит действительно стильно, черт побери! Если еще будет много текста убираться, да окошки добавить с ошибками, отладчиком… В общем, есть, куда развивать, есть. Надеюсь, это всё кто-нибудь напишет, а то у меня времени не хватит :)
Выглядит действительно стильно, черт побери! Если еще будет много текста убираться, да окошки добавить с ошибками, отладчиком… В общем, есть, куда развивать, есть. Надеюсь, это всё кто-нибудь напишет, а то у меня времени не хватит :)
я тоже пользуюсь редактором, называется idea, хороший редактор, очень много всего умеет, удобный. Честно сказать, не совсем понимаю как разделить редактор и ide, критериев нет. ide это новый виток развития «редактора» для разработки. Так что вим+плагины тоже ide. А уж каким инструментом пользоваться — каждый выбирает сам, на то и есть разнообразие.
Слово «редактор» для людей, его использующих, обычно обозначает «одна штука на все случаи жизни». Вот вы этот комментарий к статье в Idea писали? Нет? Значит она — не редактор, а «вшивая IDE», ни а что не пригодная, кроме этой вашей корявой Джавы.
(на всякий случай, я сам — Java-разработчик, а всё написанное выше — сарказм)
(на всякий случай, я сам — Java-разработчик, а всё написанное выше — сарказм)
За шесть лет коммерческой разработки не осталось, наверное, ни одной функции, которой я не воспользовался бы в любимой JetBrains IDEA. Поэтому не согласен насчёт ненужного. Насчёт монструозности и тяжести частично согласен, поэтому для совсем небольших проектов использую vim/sublime… До тех пор, пока не понадобится рефакторинг. Ни один режактор не умеет рефакторинг Java так, как его умеют IDE. И не сумеет никогда.
И не сумеет никогда
С чего вы так решили?
Потому что для, чтобы, например, вынести метод в абстрактный класс-родитель редактор должен понимать, что вообще такое абстрактные классы. А для этого он должен быть частью IDE, а не редактором.
Эмм, нет, для этого достаточно прикрутить к редактору синтаксический анализатор.
Так это и получится IDE. И в общем-то, их основное отличие от редакторов. Остальное — мелочи и дело вкуса.
А что, с вашей точки зрения, отличает редактор от IDE?
Из расшифровки IDE — Integrated Development Environment, я осмелюсь предположить, что разница заключается в том что в IDE все необходимые для разработки инструменты (редактор, синтаксический анализатор, компилятор и отладчик) собраны и положены в коробку.
В случае с редактором все это нужно собрать и положить самому, однако как только все сложено вместе редактор становится IDE следуя той же самой расшифровке.
Вывод: IDE — сумма компонент, а редактор неотъемлемая компонента IDE.
В случае с редактором все это нужно собрать и положить самому, однако как только все сложено вместе редактор становится IDE следуя той же самой расшифровке.
Вывод: IDE — сумма компонент, а редактор неотъемлемая компонента IDE.
Множество дополнительных плагинов, которые нужны для разработки на данном ЯП.
К emacs уже давно привнитили, например, синтаксический анализатор от clang для работы с C++ (не суть что криво и не всегда работае, важен факт), т.е. теперь emacs — это IDE для C++?
Смотрите выше.
Ну как таковой, явной границы между редактором и IDE нет. Я не пользователь emacs, но если он умеет понимать синтаксис C++, то считаю что да, он есть IDE для C++. Не важно, есть ли в нем дебагер, рефакторинг, автозавершение, это уже, на мой взгляд, плюшки, главное что он понимает, что это не набор слов, а текст программы.
А так-то, к сути. Есть такой момент не только среди emacs'ров, но и любых продвинутых пользователей — когда ты достаточно долго чем-то пользуешься — начинаешь строгать напильником свой инструмент доводя его до максимального КПД, я видел несколько людей, чья работа связана с офисными пакетами (написать, посчитать и п.р.), которые спустя полгода уже вовсю строчили на VB, допиливая формы. Мой товарищ, который занимается изданием нотных сборников насобирал за полгода целую кучу активно юзаемых макросов во Frescobaldi и Notepad++. Я emacs'ом начал пользоваться несколько месяцев назад «как он есть», сейчас же, имея там noweb-mode и еще пару полисинтаксических режимов — я не хочу с него слезать. Потому что к хорошему быстро привыкаешь (ну и как бы IDE не умеют полисинтаксис). А команды перестают выламывать пальцы, когда понимаешь, что как бы setxkbmap -option 'ctrl:nocaps'. К слову, дефолтные хоткеи емакса работают и в nano и в терминале, если речь о linux. Вот как бы и все. Что-то является неудобным, только если это нельзя доступно настроить.
> noweb
Вы реально что-то пишете в literate-стиле? Я так понимаю, это исключительно для себя?
Вы реально что-то пишете в literate-стиле? Я так понимаю, это исключительно для себя?
Не знаю, насколько я по Кнуту пишу, но стараюсь писать все. Я программированием не зарабатываю, и по учебе часто приходится делать какие-то расчеты и вести отчетность, т.о. я двух зайцев одновременно убиваю, и правки без геморроя сразу идут в конечный документ, да и преподавателю такой код просмотреть намного интересней
Раз уж вы пользуетесь Emacs, посмотрите ещё Babel. Он во многих отношениях занятнее, чем noweb. Можно перемешивать код на разных языках, передавать результат работы одного куска кода на вход другому, даже выполнять код на удалённой машине (через tramp).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Редактор или IDE? Очередная попытка анализа