Редактор или IDE? Очередная попытка анализа

    Хотелось бы в очередной раз поднять эту довольно спорную тему.

    С тех пор, как я начал заниматься программированием, этот вопрос не даёт мне покоя, а многочисленные темы на форумах и хабре ясности не внесли. Плюс к этому, мне кажется, некоторые аргументы как за одну, так и за другую сторону не были приведены. А у тех, что приведены, неверно расставлены приоритеты и упущен контекст.

    В статье я постараюсь исправить это упущение и расставить ещё немного точек над «ё».

    Приглашаю всех поучавствовать в поисках идеального инструмента.

    О моём опыте


    Программировать я начинал ещё в ДОС. на Turbo Pascal-е. Причём, почему-то, IDE мы тогда использовали только для отладки, и то достаточно редко. Для писания кода предпочитали использовать некий безымянный edit.exe без всякой подсветки синтаксиса в связке с Volkov Commander. И этого хватало. Этим же способом я позже занимался ассемблером и, частично, C++.

    Продолжая изучать C++ я перешел на Windows и, соответственно, Visual Studio — куда же без него. Застал версии, если не ошибаюсь, с 5 до 7. После простенького редактора это было нечто — кодогенерация и автодополнение вызывали восторг. Правда, во всём этом сгенерированном добре разобраться было практически невозможно, но это казалось неважным.

    Через некоторое время я пересел на Linux и занялся веб-разработкой на php. Здесь параллельно изучал vim и для разработки использовал ZendStudio. В какой-то момент начал использовать только Vim для всего — превратил его, в соответствии с многочисленными руководствами в маленькую ide. В нём же написал свою первую велосипедную CMS на php.

    Замечу, что до этого программирование не было основным видом моей деятельности. Да, я и для работы писал различные мелкие утилитки, делал темы для для WordPress, но основным родом деятельности было администрирование.

    Как только я занялся разработкой профессионально — возможностей vim мне перестало хватать. Был сначала eclipse, потом netbeans, сейчас — phpstorm.

    Последние пол-года героически пытаюсь освоить emacs, в т.ч. в качестве основной рабочей среды.

    Так что у меня есть с чем сравнивать и, надеюсь, моё мнение будет достаточно обоснованным и агрументированным.

    IDE? IDE...


    Я долго думал, в какой форме привести сравнение преимуществ и недостаков сторон. Список для этого не очень подходит, т.к. простое перечисление не вполне отражает суть вопроса. Редактор и IDE не противоположности, а инструменты, чья область применения перекрывается в некоторой области. Преимущества редактора далеко не всегда является недостатками среды и наоборот. По этой причине дальше идут более-менее структурированные рассуждения на тему.

    Начну, пожалуй, с одного из бесспорных преимуществ редактора — его богатых возможностей по работе с текстом и возможности всё делать не отрывая рук от клавиатуры. Cреды в большинстве своём так не умеют. Только вот нужны ли такие возможности при написании кода? При написании статьи или письма, думаю, удобно одним нажатием клавиши поменять местами 2 слова или передвинуть абзац вверх страницы. Но в тексте программы это, в большинстве случаев бессмысленно и требует рефакторинга. А платить за это приходится либо пальцедробительными сочетаниями клавиш emacs, либо не менее мозгодробительными командами в vim. А ведь это всё нужно поминать! То, что просто решается одним движением мыши, вроде перемещения окна или изменения их размеров, превращается в целый квест. Да даже выделить текст проще мышкой — точнее, быстрее, и на надо считать сколько там слов до нужнго места в тексте. Нет, программисту тоже могут быть полезны эти функции, но дело в том, что его временные затраты на собственно редактирование кода ничтожны, так что выгоды во времени не будет практически никакой. А вот значительное усложнение инструмента — налицо.

    Программист 80% своего времени тратит на понимание написанного кода и перемещению по нему. Причём перемещению именно по коду, а не по тексту! И здесь ему редактор не может помочь абсолютно ничем. Список параметров метода во всплывающей подсказке не покажет, перейти к определению метода не позволит, синтаксис не проконтролирует. А IDE, даже самые простые, с этим справляются просто и элегантно. Я недавно потратил минут 10 на поиск определения одного метода в проекте при помощи silversearcher из emacs. Оказалось, класс был определён в другом модуле и т.п. 10 минут, вместо одного клика мышкой! Я в emacs, конечно, недостаточно опытен, поэтому пусть будет 5 минут, даже минута. Но всё равно соотношение впечатляет.

    И вот здесь IDE показывает свой, пожалуй, единственный, но очень жирный плюс — это наличие синтаксического анализатор языка программирования. Среда «понимает» что она редактирует код. Редактор — нет. А это и автодополнение, и навигация, и подсветка синтаксических, а, иногда, и семантических ошибок. Кажется, излишество, приятная мелочь, баловство. Но оно, превращается в необходимость после того, как размер проекта привысит некоторый предел. А с учётом объемных современных фреймворков — этот предел наступает практически сразу.

    Да, на проекте из десятка файлов и пары тысяч строк, этот плюс не проявляет себя во всей красе. Редактор тоже может выполнять то же самое автодополнение, но он никогда не отсеет бессмысленные, варианты. И если размер проекта приближается к 100 тыс строк и состоит из тысяч файлов не считая библиотек, то становится проблемно выбирать нужное название из мешанины из названий переменных, методов других классов, да и просто слов из комментариев (было такое в vim-е у меня, не знаю, может, исправили). Интеллектуальные подсказки избавляют от необходимости помнить названия нужных функций и их параметры. Часто это просто физически невозможно.

    Кстати о проектах. Во всех IDE есть такое понятие. К нему привязываются настройки, ресурсы, можно осуществлять поиск и т.п. В редакторах это в лучшем случае открытый каталог файловой системы. Иногда чуть больше.

    Интеграция с отладчиком в редакторах тоже оставляет желать много лучшего. Юнит-тестирование, логирование в какой-то мере спасают ситуацию, но, иногда без отладчика никуда.

    Кто-то может возразить, что в современных редакторах многие из этих функций уже реализованы и ничем не уступают самым навороченным IDE. Не соглашусь. Во-первых, полноценных реализаций нет. Не работают они, как должны. Во-вторых, установка всего этого уже достаточно сложная задача. Да даже конфигурация внутренних функций редактора уже нетривиальна. Попробуйте, скажем, включить нумерацию строк в том же emacs! Плюс ко всему, часто нужный функционал реализуется десятком плагинов непонятно как между собой взаимодействующих. А часто ещё и имеющих десяток версий и веток, не всегда совместимых, странно настраиваюхся и т.п. Можно, конечно, потратить месяц, всё настроить и установить (что тоже удел энтузиастов), но это всего лишь приблизит редактор к уровню IDE. К примеру, вернёмся к тем же проектам — я пробовал и Project под vim и projectile под emacs и ещё некоторые плагины. Если Project ещё более-менее отвечает моим требованиям (хотя в последней версии мне вообще не удалось создать проект из-за багов), то projectile оставил исключительно негативные впечатления.

    И тем не менее, у редакторов есть несколько областей применения, где они, как минимум, составляют достойную конкуренцию средам разработки.

    Во-первых, они себя лучше показывают на мелких проектах. Нет смысла загружать IDE-комбайн для работы с проектом в 10-20 файлов. Проще в редакторе подправить 3-4 строки.

    Во-вторых, в некоторых специфических областях все преимущества IDE нивелируются. Например, низкоуровневая разработка для linux. Я этим не занимался, но, судя по структуре кода и предпочтениям разрабочиков (около 70% — emacs и клоны, 25% — vim, 5% — какая-то экзотика вроде jed), IDE там делать нечего. Весь нужный код, с которым происходит работа, собран, как правило в одном-двух файлах, и не нужно прыгать в пределах всего проекта. Да и не сильно поможет автодополнение при выборе из десятка-двух функций с почти одинаковыми названиями.

    В-третьих, редакторы могут работать не только с кодом. Всю их мощь можно задействовать при работе с csv или xml файлами. Либо чего-то другого, в чём иногда возникает необходимость, вроде статьи или письма. И не нужно переучиваться, искать удобную программу или запоминать горячие клавиши — всё под рукой, всё одинаковое.

    В-четвёртых, возможность работы с языками, для которых нет вменяемой IDE. Скажем, с тем же ruby мне среда не сильно помогла. SublimeText-а оказалось достаточно. Хотя с большим ruby проектом я не работал, возможно, там бы IDE себя показала.

    И в-пятых, пресловутая возможность расширения. При наличии хороших плагинов редактор становится очень удобным! Плюс специфическое удовольствие непрерывного тюнига своего основного инструмента и ощущение полного контроля над ним — дорогого стоит.

    Итого


    Я не очень люблю IDE, хотя так могло показаться по предыдущему тексту. Считаю их довольно монструозными, с кучей ненужных функций, медленными и требовательными к ресурсам. Да и лучшие из них довольно дорогие. Кроме того, я считаю, использование IDE расслабляет, и привязывает к себе. У редакторов, соответственно, всё наоборот. Плюс доступность и возможности тонкой доводки под себя. По крайней мере vim и emacs. В конце концов, они мне просто нравятся. Эту статью, например, я пишу в Emacs.

    Но индустрия (и начальство) диктует свои требования. Если не использовать IDE, производительность значительно упадёт. Но никто не даст вам пол-часа на поиск пропущенной запятой в 10 тыс строках кода. Это всё должно выполняться автоматически и автоматически же исправляться. Мне тоже иногда нравится покопаться в коде без всяких инструментов — но на работе это непозволительная трата времени.

    После всех своих проб и ошибок я сделал такой вывод — редактор можно использовать для разработки, но с IDE, после определённого предела он не сравнится и использование редактора для чего-то, за что вам платят — непозволительная роскошь. Да, если использовать правильные практики разработки, правильно проектировать/документировать код, следовать стандартам — можно сгладить врождённые недостатки редакторов. Но мы живём далеко не в идеальном мире, поэтому использование IDE — необходимость, независимо от нашего желания.
    Поделиться публикацией

    Комментарии 380

      0
      IDE — необходимость, независимо от нашего желания.

      Необходимость, ага. У меня половина коллег кодит в виме. Многие в саблайме. Некоторые виндусятники в нотпаде++.
      В IDE — меньшинство знакомых (почти только джависты). Вот такая вот необходимость.
        +3
        А на чём кодите (Вы и коллеги/знакомые), если не секрет?
          +1
          C/С++, python, Go, js — масштабно, ну и так, балуюсь на всем по мелочи.
          Я себе для веба даже поделку под ST сделал: packagecontrol.io/packages/Color%20Highlighter.
            0
            Ну я понимаю компилируемые языки, но тот же js...Webstorm ведь шикарен для разработки, и поделки не нужны, всё в коробке.
              –1
              WebStorm не подерживает синтаксис для JSX (ReactJS) файлов, пришлось переходить на Atom.
                +7
                уже поддерживает http://blog.jetbrains.com/webstorm/2014/10/webstorm-9-released-meteor-support-react-and-jsx-gulp-integration-and-more/
              –9
              C/С++, python, Go, js — масштабно, ну и так, балуюсь на всем по мелочи.

              По-моему ни для одного из этих языков нет IDE, в которой бы сносно работал рефакторинг (более сложный, чем rename). А без рефакторингов IDE это действительно просто текстовый редактор с подстветкой, обвешанный парой плагинов. Отсюда и мнение что IDE не нужно.
                +4
                Отвечу за С++:
                • Visual Studio + Visual AssistX\Resharper C++
                • CLion
                • QtCreator


                Вещи типа автоматического включения инклюдов, выноса кода в метод, переименования сущностей, реализация стабов методов интерфейса, навигация по коду, подсветки, подсказок, автодополнения — работают очень хорошо.
                  +1
                  А Вы код ядра пробовали в CLion открыть и что-нибудь попытаться написать новое? И завязка на CMake имхо сильно сковывает, когда куча проектов на обычном gnu make.
                    0
                    И завязка на CMake имхо сильно сковывает, когда куча проектов на обычном gnu make.

                    Хм, а в чем конкретно вас сковывает cmake?
                      0
                      Тем, что надо прописывать ВСЕ исходники со всеми подключаемыми либами. Все как в make, но вот ни о каком автодополнении и прочих сладостях CLion и думать не приходится, пока все это не опишешь в конфиге. И по маске добавить нельзя. Вот честно, искал решение и не нашел, все уверяют, что надо четко каждый файл прописывать. А на больших проектах, где 100500 файлов, типа squid, для того чтобы чтото поправить, надо с нуля сборку написать. Ну это разве нормально?!
                        0
                        Честно говоря не понял о чем вы… писать cmake-скрипты и проще и быстрее, чем обычные make'и… а вот то, что в CLion оно работает как-то не так… ну это проблема этой IDE, а не cmake'а.
                          0
                          Честно говоря не понял о чем вы…

                          О том, что нужно переписывать всю систему сборки только ради того, чтобы воспользоваться IDE. У нас, например, свой build-framework, основанный на make, который во многом удобнее изкоробочного cmake. У некоторых коллег есть лицензия CLion, но они так и не смогли его эффективно использовать — код компилируется на удалённом сервере + система сборки — не cmake.
                            0
                            Написать — проще. Портировать существующую сборку с нуля на XXX — бывает архисложно. А делать это, только, что бы открыть код в IDE вообще моветон. В QtC это элегантно решили.
                              0
                              Почему архисложно? В большинстве случаев под платформу XXX уже есть cmake и можно собираться нативно на таргет-устройстве. А для кросскомпиляции достаточно написать правильный toolchain файл. При этом голые make'и под банальный Windows уже придется собирать либо под MinGW, либо переписывать все на nmake, что не очень интересно.
                                +3
                                Вы пытаетесь подменять понятия: в ответе на habrahabr.ru/post/265197/#comment_8545795 и на мой комментарий выше.

                                Объясняю: речь про CLion. Он может сейчас эффективно работать только с CMake проектами. Это и есть завязка — завязка CLion на CMake. Вы же начинаете про скованность самого cmake. Да никого он не сковывает, просто есть куча проектов которые его не используют. И работать с ними в CLion — сложно и неудобно.

                                Теперь про портирование. Ядро Linux не использует CMake для сборки. Попробуйте портировать с kbuild на CMake — это и есть портирование. Да, если проект использует уже CMake, то написать грамотный тулчейн и вуаля. Главное, что бы кривожопость некоторых авторов правил в CMakeLists.txt не приводила к мукам. А такие криворучки попадаются на удивление часто.

                                Вроде всё по полочкам разложил.
                  0
                  Ничего себе поделка, топ100 значок имеет)))
                    0
                    Это только потому, что там нет значка топ30!
                    А если серьезно, то не такое уж и достижение, там кода-то совсем ничего, и большая часть — обходы косяков апи ST.
                  0
                  del.
                    0
                    Вообще, я ни в коем случае не говорю, что ИДЕ — отстой, не пользуйтесь ИДЕ. Просто есть неопровержимые доказательства отсутствия необходимости и факта первостепенности именно нашего желания.
                      +1
                      Не, ну если «обычный» текстовый редактор после довеса парочки плагинчиков делает то, что должна делать IDE, то волей-неволей грань стирается…
                    +9
                    почти только джависты
                    Вот, кстати, да — в Java без IDE практически никак. Нет, конечно, можно программировать на Java и в редакторе, даже не в FAR с подсветкой синтаксиса, а вообще в Notepad без плюсов, но это экстрим, и так можно писать только если скорость написания и читаемость кода не волнует и рефакторить и «облагораживать» код не собираются. Java вообще интересный язык в этом плане — как будто настроена на то, чтоб извлекать пользу из IDE по максимуму. Наверное, из-за строгой типизации и изначально безопасного кода.
                      +1
                      С Java всё весьма просто объясняется :) Из-за указанной вами строгой типизации и кучи стандартов/договоренностей, принятых в языке, которые не только упрощают разработку, но и помогают избежать кучи ошибок, на Java пишутся программы такого масштаба и сложности, который часто и не снился большинству других языков. Привет из Java Enterprise, в котором миллион строк кода — небольшая программа. Причем я одно время такую рограмму разработал и целый год поддерживал в паре с еще одним разработчиком. Вдвоем за 3 месяца написали, вдвоем год улучшали. Почти ни на одном другом языке такое даже не снилось (вероятно, конкуренцию могут составить C#, ruby и, возможно, python, но про последний — сомневаюсь).

                      А в проектах такого размера без IDE с ее быстрым контекстным поиском, автодополнением, переходом от одного куска кода к другому в один клик и т. п. — не обойтись.

                      А для C++, кстати, весьма неплох eclipse. Особенно для гибридных проектов C/C++ + Java. Там вообще пока альтернатив нет. Он, конечно, Си понимает хуже, чем родную Java, которую даже компилирует сам, вообще без участия javac, но всё равно неплохо.
                      +13
                      У нас в команде из 10 человек, все пользуются исключительно PHPStorm.
                      Те кто предпочитают vim, notepad — значит такие программисты или мазохисты, или времени бесконечно.
                      C IDE процесс разработки превращается в рай и время на разработку продукта сокращается во много раз.
                        –10
                        Или они достаточно квилифицированны. Vim даёт невероятный прирост скорости.
                        Чтобы изучить PHPStorm тоже надо время.
                          +1
                          vim дает прирост скорости?
                          Уж по мне так sublime интереснее.
                          Ну и vim надо еще изучать, или хотя бы переписать все хоткеи как в популярных редакторах.

                          Какой бы программист не был, с IDE он все равно будет быстрее писать код, видеть все ошибки и т.д. Он будет погружен полностью в проект, чувствовать каждый кусочек. Тысячи файлов должны быть как единый организм, а не как куски не пойми чего.
                          Вы ведь должны понимать, что скорость и качество, это главное в нашей работе, если конечно вы работаете не на себя.

                          P.S.
                          Для работы с PHP использую исключительно IDE PHPStorm.
                          Для работы с Go — sublime
                            0
                            Просто Вы не знаете vim, ничего переписывать там не надо, потому что в vim'е нет хоткеев в привычном понимании этого слова.
                            Кстати, я тоже использую PHPStorm, но с плагином IdeaVim.
                              –4
                              Когда пользуюсь vim, всегда использую простые хоткеи, тот же shift+ZZ or shift+ZQ.
                              Значит есть хоткеи, просто они совершенно отличны от всего софта.
                                +2
                                Это не хоткеи. Это команды, которые могут складываться вкомбинации, как буквы складываются в слова.
                                +1
                                Вот так всегда… Как только кто-то говорит, что IDE лучше чем vim/emacs, потому что — 1,2 и 3, контраргумент — «вы не знаете vim!»… Аргх
                                  +9
                                  Потому что это пустой спор, в нём не нужны аргументы.
                                  По мне, в IDE есть редактор текста и он проигрывает как редактор и VIM и Emacs.
                                  Для себя я решил всё проще: я работаю в IDE, но когда надо что-то отредактировать, я нажимаю горячую клавишу и оказываюсь в VIM, выполняю то, что хотел, и снова оказываюсь в своей IDE.
                                  Для меня это оказалось гораздо комфортней, чем отсутствие средств IDE в редакторе, или отсутствие нормального редактора в IDE.
                                    –6
                                    Тема холиварная. IDE — это сумма компонентов для удобного управления проектом (а он может быть большим). Например, моё личное мнение, что если кто-то будет писать на Java в vim/emacs, то этот человек жутчайший извращенец.
                                +7
                                Какой бы программист не был, с IDE он все равно будет быстрее писать код, видеть все ошибки и т.д.

                                Не нужно голословных заявлений ;)
                                –3
                                Про PHP не скажу. Про Java скажу. Посмотрел бы я, как вы в Vim будете анализировать и разбираться в проекте классов так на 100-150. На одно только переключение и поиск имплементаций интерфейсов, например.

                                Использование Vim при наличии продвинутой IDE говорит либо о том, что вы — пожилой специалист с закостенелыми привычками, которому трудно изучить новый инструмент, либо, что вы — студент, который чувствует себя более уверенно, работая в текстовом редакторе, из которого сверстники даже выйти не могут без его помощи (понты же!), либо человек, который просто не стремится выжать из окружения максимум возможностей. Очевидно, что среда, заточенная под конкретный ЯП, будет и удобнее, и эффективнее. Но загвоздка в том, что ее надо настраивать, изучать (а современные IDE сложны), а это — лень. А без адекватной настройки она — да — будет скорее мешать, увы.
                                  +2
                                  Но загвоздка в том, что ее надо настраивать, изучать (а современные IDE сложны), а это — лень. А без адекватной настройки она — да — будет скорее мешать, увы.

                                  Интересно, что большинство сторонников IDE здесь в комментариях придерживаются как раз мнения, что настраивать нужно «редактор».
                                    +1
                                    Настройка настройке — рознь. Есть такая категория пользователей, которые готовы написать сто консольных команд и попроавить 50 строк в конфиг-файлах, но пассуют перед простым окошком «Properties». Просто так устроен их мозг, что GUI он не воспринимает. Я собственными глазами видел пару таких разработчиков. Они мучались и «жрали кактус», долго пытаясь превратить vim в недоделанный eclipse. И в итоге, когда я им показывал, что чтобы обновить список импортов во всем проекте, надо дважды кликнуть мышкой по менюшке, кривились: «как же так! серьезные программисты не пользуются мышью!»

                                    На мой взгляд, основу такого отношения (в случае Java) закладывает снобизм. Человек не стремится решать задачу эффективно. Он стремится решать ее красиво. В смысле — красиво выглядеть в процессе решения. Это — психология, как я думаю. Рациональные доводы здесь ни при чем.
                                      0
                                      И еще — про «долгую настройку». Я тут уже в комментах где-то писал, что по моим критериям «долгая настройка» — это полчаса-час после установки IDE. При условии того, что проект сложный и реально нуждается в этой долгой настройке. А ответил я это человеку, который сказал, что он…

                                      Вот этот комментарий: habrahabr.ru/post/265197/#comment_8545391

                                      Просто несколько разные масштабы времени соответствуют в нашем сознании понятию «долгая настройка».
                                      0
                                      Т.е. изучать и настраивать вим им не лень, а идешку они не осилят? Ну, возможно, мышкой будут по кнопкам промахиваться.
                                      Вообще Ваш комментарий довольно оскорбителен и категоричен.
                                        –1
                                        изучать и настраивать вим им не лень, а идешку они не осилят?

                                        Прочтите мой предыдущий комментарий, пожалуйста. Краткий ответ: да, не осилят, потому что недостаточно мотивации. Не хотят они ее осиливать — она не соответствует их чувству прекрасного.

                                        Вот я, к примеру, люблю Eclipse и не люблю Idea. С эстетической точки зрения. Рациональных аргументов в пользу того или другого почти нет — просто это две разных «культуры» разработки на Java. По функционалу они близки, поэтому я долгое время имел возможность выбирать ту, которая мне по душе и не чувствовать себя отстающим.

                                        Но сейчас мне «по долгу службы» пришлось влезть внутрь IDE — делаем плагины для Android Studio — и тут уже, увы, приходится изучать Idea и пользоваться ею. Я мог бы до конца «стоять на своем» и упорно всё кодить в Eclipse, но я лучше буду знать обе среды в равной степени — тогда у меня будет больше аргументов при «холиварах» ;)

                                        А если серьезно, то ничего оскорбительного, на самом деле, я сказать не хотел. В основном, как и везде, программисты — адекватные люди, которые выбирают инструмент к задаче. Но бывают, согласитесь, отдельные «упоротые» индивиды, которым не важно, что делать — лишь бы не учить эти мерзкие кнопочки-окошечки. Вот про эту категорию я и высказывался.
                                          0
                                          Привычка. У меня сейчас похожая ситуация с Visual Studio, но там ReSharper есть, не так больно.
                                            0
                                            Привычка — злейший враг представителя профессии, в которой, если верить «отцам», необходимо изучать в год по одной совершенно новой, незнакомой технологии. И с ней следует бороться, так как она ограничивает творческий и трудовой потенциал.
                                              0
                                              Поддерживаю. Периодически надо ломать себя, кругозор как-то шире становится.
                                                0
                                                Кругозор становится шире, но память не резиновая… новое постепенно вытесняет что-то так же необходимое. Не у всех достаточно большой объем памяти чтобы безболезненно постоянно изучать новое и не забывать насущное.
                                +21
                                Я считаю что есть только один критерий оценки — время жизни. Если в редакторе и ИДЕ одинаковый результат получается за разное время, то победитель тот, у кого это время ниже. И ИДЕ значительно чаще дает этот выигрышь по времени. Ничего не ценно так, как время разработки (опять же, при всех остальных прочих равных, подразумевается что код на выходе идентичный). Даже самая последняя ИДЕЯ и Вебшторм на многомегабайтных проектах запускается за 5 секунд на далеко не свежем компьютере, а если это не так, ну это же ваш рабочий инструмент, вы им зарабатываете деньги и не можете обеспечить себе комфортное рабочее место?
                                А про поддержку CSV, XML, и тд в ИДЕ это вообще отдельная история. ИДЕ не только обычно поддерживают их лучше, но и понимают семантику, могут поставить перекрестные ссылки и дополнять нужные ключи, как например .properties в java или свякзки angular.js и HTML, все это гарантированно экономит время, и вспоминания, и навигации.
                                Практически единственный момент (который тоже не всегда применим), это когда необходимо поменять что-то на уже рабочем сервере. Но для многих языков это невозможно — нужна перекомпиляция, или подход с деплоем не позволяет так просто пойти на сервер и менять файлы. В остальных всех случаях у редакторов нет никаких шансов перед ИДЕ (стоимость не берем во внимание).
                                Кроме того, ИДЕ это просто продолжение идеи редактора, а не паралельная ветвь эволюции. Ведь редактор с пониманием семантики русского языка становиться сразу же ИДЕ русского языка. Почему бы им не пользоваться при наличии?
                                  0
                                  Без редактора тоже не очень хорошо. IDE не сильно заточены, к примеру, для открытия огромных файлов.
                                    0
                                    Идея на работке спокойно открывает файлы в 6к+ строк, работает мгновенно, навигация мгновенная
                                      0
                                      Огромные файлы — это 100 мегабайт, 1200 мегабайт. Всякие CSV, XML выгружаемые.
                                      Вот тут-то уже IDEA не справится. И Atom, и Sublime тоже спасуют. Только vim и спасает в таких случаях.
                                        +6
                                        ИМХО, файлы такого размера не открывать надо, а запросы по ним гонять через всякие grep, а лучше — через инструменты, предназначенные для этих конкретных файлов. Слабо себе представляю что вменяемого можно сделать открыв 100-мегабайтный текстовый файл.
                                          0
                                          Как то на работу принесли огромедный файл выгрузки из одной известной системы похозяйственного учета. Содержимое этого файла было нам не известно, но его нужно было подготовить к загрузке в базу данных. Как вы бы предложили «гонять по нему через всякие grep» даже не взглянув на содержимое?
                                            +7
                                            head -n20 ogromenny.txt
                                              +2
                                              неа, там все в 1 строку. XML знаете ли. Да и первые хз сколько байт там были заполнены не нужной нам в базе инфой.
                                                +11
                                                head -c 2000 file.xml
                                                  0
                                                  А как вы потом читать будете эти 2000 символов и разбираться, что к чему?
                                                  +14
                                                  ~$ xmllint --format --recover ogromenny.xml 2>/dev/null | head -n20
                                                    0
                                                    А чем хуже: vim ogromenny.xml — ?
                                                      0
                                                      А зачем вообще его читать в текстовом редакторе? Загрузите его сразу Xml-парсером любимого языка. Скажем, я бы открыл его парсером Java. А потом включил режим отладки и в окошке Watch (слыхали?) писал бы запросы на вложенные конструкции, изучал бы семантику, правил код чтения… что там вы собирались вообще с этим XML делать?

                                                      На кой черт мне XML самому глазами парсить?
                                                        0
                                                        А ничего, что вы его еще в глаза не видели и не знаете, есть ли там данные для загрузки в базу или нет? Или вы сначала попробуете программу загрузки написать, а уже когда поймете, что там не XML, а бинарник, решите остановится? )))
                                                          0
                                                          Хм… я так понял, что речь именно про XML. Ну да ладно.

                                                          На самом деле, я просто считаю, что способность открывать текстовым редактором файлы по 100 мегабайт — вещь во-первых редко используемая в реальной жизни, а во-вторых, не входящая в спектр первой необходимости для IDE. С этим, конечно, vim справится лучше (он же писался для терминалов, где пропускная способность канала до сервера была сопоставима со скоростью набора текста). Но при сегодняшних объемах оперативной памяти… В общем, любой простой редактор это может. И многие не тормозят при этом. TextWrangler, например. Ну, сожрет он эти 100 мегов из памяти — ну и черт с ним.
                                                            +1
                                                            Да, так и есть. Просто когда вы пользуете Vim для написания программ, а затем его же для других, околопрограммистских действий, это довольно удобно.
                                                        0
                                                        отсутствие автоформатирования xml из коробки.
                                                        но, по правде признаться, код выше я как раз и выдрал из своего .vimrc, в котором и исправляется этот досадный недостаток =)

                                                        au FileType xml exe ":silent 1,$!xmllint --format --recover - 2>/dev/null"
                                                  +3
                                                  Для предварительного взгляда на содержимое использую FAR. И вообще использую его как основной файловый менеджер.
                                                    0
                                                    Не получится там предварительно взглянуть на содержимое. XML файл без какого либо форматирования в 1 строку.
                                                      0
                                                      Для XML использую Notepad++ с соответствующим плагином. Для FAR тоже есть плагин, который представляет XML как папку, но это неудобно.
                                                  0
                                                  Заменить пользователя в схеме огромной БД для разворачивания на локале, например.
                                                    –1
                                                    Развернуть как есть, подключиться с правами DBA, понаделать всё что хочется с юзерами.
                                                  +1
                                                  ide для кода, а не для жирных файлов данных, внезапно!
                                                    0
                                                    Я тут как сторонний наблюдатель, но вроде как речь именно о том, что IDE не для всего хорошо подходит, и на задаче открытия жирных файлов данных лучше ведут себя редакторы.

                                                    Вопрос не по теме, но очень любопытно: а что у вас в файле на 6к+ строк? Это же реально много :)
                                                      0
                                                      Легаси там. Суммарно несколько миллионов строк в проекте, не один десяток файлов в 1к+ строк
                                                        0
                                                        В файле с юнит-тестами clang-format более 10к строк кода (clang/unittests/Format/FormatTest.cpp). Там даже Emacs иногда притормаживает :)
                                                          0
                                                          Редакторы для открытия файлов данных? Обычно такие файлы открываются для изучения, а не изменения (а за изменения в авто-генерируемых файлах надо давать по рукам!) — там простого просмотровщика хватит.
                                                            0
                                                            Мне тут на прошлой неделе прислали SQL дамп с лишними символами вначале файла, мол, ты ж инженер, сам разберёшься.

                                                            В любом случае, если есть инструмент, не вижу смысла его не использовать.
                                                              0
                                                              Редакторы любят загружать значительный кусок/весь файл в память, всяческие вьюеры стараются не кэшировать такие размеры, а читать по мере надобности…
                                                                0
                                                                Так какое решение для ситуации с побитым SQL дампом вы предлагаете?
                                                                  0
                                                                  Это печально, когда складывается ситуация, когда _надо_ подредактировать генерируемый файл данных. Вообще это ставит под сомнение валидность данных вообще (а не только в начале файла).
                                                                  Поэтому я стараюсь таких ситуаций избегать… Если всё-же приходится — беру простейший, без обвеса редактор и им правлю — такие редакторы не стараются закешировать всё что надо и что не надо.
                                                                    0
                                                                    Ну т.е. в итоге всё равно приходим к задачам, с которыми IDE справляются плохо :) Это не значит, что использовать IDE плохо — большинство задач не включают в себя редактирование больших файлов — но это отвечает на вопрос, когда редактор лучше IDE.
                                                                    0
                                                                    Когда-то давным-давно была написана утилитка, которая при помощи простых инструкций могла собирать файл из разных кусочков. Как раз для таких случаев, когда во время дискет была необходимость править 1-2 байта в файлах по 100Мб которые тогда не открывались ни в одном редакторе.
                                                                    Думаю такую программу можно набросать на любом языке под конкретную однократную задачу.
                                                              0
                                                              Откройте исходный код какого-нибудь парсера. Или какой-нибудь контроллер серьезного серверного приложения. Мало ли…
                                                      +1
                                                      И ИДЕ значительно чаще дает этот выигрышь по времени.

                                                      Вот из этого утверждения у вас и складывается позиция, а оно далеко не всегда верно. Я не буду спорить или что-то вам доказывать, но приведу пример, когда «редактор» значительно выигрывает у 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 строк и увидеть результат всех выражений.

                                                      Я не знаю, насколько распространён такой подход (да и мне, по большому счёту, всё равно), но для меня «редактор» даёт существенный прирост скорости разработки, а никак не её уменьшение.
                                                        0
                                                        Документация говорит, что достаточно выделить и нажать ALT+SHIFT+E.
                                                        В другом месте документации правдо сказано, что нажимать надо ALT+SHIFT+I.
                                                        Но так или иначе для этого есть сочетание кнопок.
                                                          +2
                                                          Для того, чтобы отправить выделенное — да, наверняка. А чтобы отправить текущую строку? А текущее определение? А если кроме Python вы иногда пишете на Ruby, Clojure или Julia? Я могу вам привести две страницы примеров, когда Emacs значительно ускоряет разработку по сравнению с традиционными IDE. IDE заточены под определённый, достаточно узкий круг задач и возможностей. Редакторы более широкого профиля (а это, кроме Vim и Emacs, также Sublime Text, Atom, LightTable и другие) предоставляют из коробки только основные фичи, но практически неограниченные возможности через расширения. Говорить, что одно в принципе лучше, чем другое — это как-то странно.
                                                          0
                                                          Выделяете кусок кода (удобнее всего с помощью Ctrl+W инкрементально выделять), затем Alt+Shift+E и код будет исполнен. И в PyCharm (как и любой другой IDE на основе IDEA) можно практически на любое действие навесить хоткей.
                                                            +1
                                                            А создать действие «выделить текущую строку и отправить её в REPL» можно?
                                                              0
                                                              Можно макрос записать и забиндить его на кнопку.
                                                                +1
                                                                Может быть я не слишком изощрён в записывании макросов в IDEA, но простой макрос «перейти в конец строки, выделить всё до начала строки, нажать Alt+Shift+E» у меня получился довольно кривой: первые пару строк посылает нормально, потом сбивается. Почему сбивается — непонятно, ибо всё, что у меня есть — визуальное отображение действий, что там происходит внутри я не знаю.

                                                                Так или иначе, я могу очень просто усложнить задачу. Как я уже говорил выше, достаточно попробовать отправить в REPL всё выражение (например, функцию). Или открыть в бразере страницу из документации по текущей функции. Или автоматически найти и перейти в корень проекта. Или переключаться по одной горячей клавише между редактором и REPL-ом. Или сделать что угодно из этого удалённо по SSH.

                                                                Именно такие кастомизации делают программируемые редакторы такими крутыми, и позволяя автоматизировать любые рутинные действия, какими бы сложными они ни были.
                                                                  0
                                                                  Я вам сейчас целый мир открою:
                                                                  www.jetbrains.org/intellij/sdk/docs

                                                                  С помощью вот этого великого знания вы можете добавить к IDEA абсолютно любую фичу. Вот прям совсем-совсем. Вплоть до поддержки нового языка, компилятор ккоторому накодили под пивко на выходных. А уж взять код имеющегося плагина (если он open-source) и добавить в него простую фичу — это вообще час-два работы.
                                                                    +1
                                                                    А уж взять код имеющегося плагина (если он open-source) и добавить в него простую фичу — это вообще час-два работы.

                                                                    Час-два работы — это круто. Последнюю фичу в Emacs — переключение на консоль и переход в конец буфера — я написал примерно за 10 минут. Вы бы как раз к этому моменту докачали код плагина и открыли проект.

                                                                    И давайте на чистоту: как много пользователей IDEA пишут для неё плагины? Для пользователей Emacs это обычные и даже немного рутинное дело.
                                                                      0
                                                                      У пользователей IDEA всё из коробки есть. Если нет силько кастомных фич, то или смериться, или писать плагин. Тут идеология совершенно другая: за деньги тебе дают готовый к использованию продукт.
                                                                        0
                                                                        Последнюю фичу в Emacs — переключение на консоль и переход в конец буфера — я написал примерно за 10 минут


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

                                                                        И, да, вы правы. Пользователи Eclipse в среднем пишут плагины довольно редко — за них это сделали профессиональные писатели Eclipse-плагинов.
                                                                          0
                                                                          а вы, очевидно, написали, сколько времени будете вводить код плагина.

                                                                          Нет, я написал полное время разработки — от появления необходимости, до готовой к использованию фичи.
                                                                            0
                                                                            На каком это языке?
                                                                              +1
                                                                              Emacs Lisp, вестимо.

                                                                              Вам бы почитать, что из себя представляет init.el, и как его можно использовать для кастомизации редактора.
                                                                                –1
                                                                                Я lisp действительно не знаю. Просто интересно было оценить объем требуемого кода. В любом случае смысла большого в этом нет. Просто полюбопытствовал. Я сам 10 минут бы только разбирался в том, как писать эти расширения. Разумеется, пользоваться средой, в которой навык написания расширений входит в базовый набор навыков для ее использования, я бы не стал. Даже Linux на десктопе сейчас уже ушел от подобного уровня недоработанности.
                                                                                  +1
                                                                                  Разумеется, пользоваться средой, в которой навык написания расширений входит в базовый набор навыков для ее использования, я бы не стал.

                                                                                  Не входит, пользуйтесь на здоровье базовой версией.
                                                                  0
                                                                  С точки зрения IDEA — это 2 разных действия, одним хоткеем не получится, к сожалению. Но можно, как написали выше, сделать макрос.
                                                                  В настройках можно сделать хоткей на выделение всей строки: Select Line at Caret.
                                                                  P.S. Я почти всегда пользуюсь Ctrl+W — это очень удобно.
                                                                +8
                                                                85% времени при разработке на Python я провожу в режиме «написать функцию -> проверить в REPL». Т.е. подавляющее большинство операций, которые я выполняю, напрямую связаны с переключением между текстовым редактором и REPL.

                                                                У вас это вместо тестов чтоли? Не могу представить зачем это может быть нужно глядя на ваше «85% времени разработки».
                                                                  –8
                                                                  Боюсь, что это тесты очень часто используются только из-за того, что в языке нет REPL. Последний сценарий, который я делал в REPL:

                                                                  1. Создать объект, открывающий соединение с БД.
                                                                  2. Вызвать несколько методов.
                                                                  3. Посмотреть, что изменилось в БД, проверить логику.
                                                                  4. Загрузить датасет с подозрительными результатами, преобразовывая каждую запись к объекту модели.
                                                                  5. Найти ошибку.

                                                                  REPL, правда, Scala-овский, в нём заменять определения на лету достаточно тяжело, поэтому пофиксить ошибку на лету не получилось. Но сценарий явно не подпадает под определение «вместо тестов».
                                                                    0
                                                                    Я искренне не понимаю что вы с этими REPL'ами делаете. Как вы определяете, что остальной код не сломался из-за ваших правок? Тоже REPL руками? Перед каждым коммитом?
                                                                      0
                                                                      Вы путате тёплое с мягким. Если вам нужны регрессионные тесты, вы пишете тесты. Если вам нужна интерактивная разработка, вы используете REPL. Если у вас нет REPL, тогда да, в некоторых сценариях вы можете заменить его REPL-ом и гонять небольшие куски кода прямо из IDE. Но, как я уже показал выше, работает это далеко не всегда.
                                                                        +5
                                                                        Не уверен что с чем я путаю, но ваш подход очень напоминает подход начинающих — когда пишется маленькая демо-программка, которая воспроизводит интересующий сценарий, а после этого благополучно удаляется. Разница между такой программкой и тестом только в том, что тест в итоге остаётся.
                                                                          0
                                                                          Ок, пример с БД, где мне нужно интерактивно исследовать поведение системы, вас не впечатлил. Попробуем по-другому.

                                                                          Прямо сейчас у меня открыт код классификатора изображений. Суть моей работы состоит в исследовании, какие преобразования над изображением и какие параметры классификатора дают оптимальный результат. В начале работы я загружаю весь набор изображений в память, что занимает примерно 2 минуты. Затем я беру какое-нибудь изображение и начинаю применять к нему фильтры, пытаясь определить, какой из них даст нужные мне признаки. При этом каждый раз я вызываю в REPL функцию применения фильтра и отображения результата на экран.

                                                                          После того, как я подобрал фильтр-кандидат, я обучаю и кросс-валидирую классификатор-кандидат, что занимает около 1.5 минут. В зависимости от результатов классификатора, я принимаю решение, заменить ли классификатор, заменить ли фильтр, заменить ли их параметры и если да, то на какие.

                                                                          Каждый следущий шаг зависит от результатов предыдущего. И каждый шаг занимает определенное количество времени, поэтому перезапускать всё сначала и терять, например, уже обученный классификатор — неприемлимая потеря времени. REPL позволяет поддерживать такую разработку. Скажите, как юнит-тесты помогут мне в этой задаче?
                                                                            +3
                                                                            как юнит-тесты помогут мне в этой задаче?

                                                                            Никак. Вы прыгнули с задачи про «соединение с БД и поиск ошибки» на задачу а-ля матлаб.

                                                                            Давайте теперь предположим, что вы дошли до 10-го шага, когда должны получиться там какие-то финальные результаты, но получается полная хрень. И тут вы осознаёте, что ошибка была где-то на шаге 3. Будь это отдельный скрипт — открыли, поправили, запустили и пошли пить кофе. В вашем же случае нужно участие человека.

                                                                            А теперь давайте предположим, что к вам в команду пришёл новый сотрудник Вася и просит поделиться с ним вашими наработками. Вы ему дамп процесса python снимете и попросите восстановить на его машине? Попутно рассказывая, что первый шаг это 8 раз вверх, второй — 6, а если 4 вверх, то там ошибка, и результаты никуда не пошли?
                                                                              0
                                                                              Никак. Вы прыгнули с задачи про «соединение с БД и поиск ошибки» на задачу а-ля матлаб.

                                                                              Задача про БД ничем принципиально не отличается от задачи «а-ля матлаб» — и там, и там у вас есть данные и/или функции, которые нужно исследовать и в зависимости от результата решить, что делать дальше. Я вам могу ещё с десяток таких же примеров привести, начиная от работы со сторонними API и заканчивая зажиганием лампочек на Raspberry Pi, где интерактивная консоль экономит уйму времени при разработке. «При разработке» здесь ключевое слово.

                                                                              Давайте теперь предположим, что вы дошли до 10-го шага, когда должны получиться там какие-то финальные результаты, но получается полная хрень. И тут вы осознаёте, что ошибка была где-то на шаге 3. Будь это отдельный скрипт — открыли, поправили, запустили и пошли пить кофе. В вашем же случае нужно участие человека.

                                                                              А кто вам запрещает иметь рядом скрипт? Собственно, я ещё в самом первом комментарии написал:

                                                                              В Emacs у меня обычно открыто 2 буффера — один для кода, а второй с REPL.

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

                                                                              А теперь давайте предположим, что к вам в команду пришёл новый сотрудник Вася и просит поделиться с ним вашими наработками. Вы ему дамп процесса python снимете и попросите восстановить на его машине? Попутно рассказывая, что первый шаг это 8 раз вверх, второй — 6, а если 4 вверх, то там ошибка, и результаты никуда не пошли?

                                                                              Аналогично, Вася получит кодовую базу, ничем не отличающуюся от той, что кто-нибудь мог бы сделать в PyCharm и/или без REPL.
                                                                          0
                                                                          заменить его REPL-ом

                                                                          Заменить его unit-тестами, конечно же.
                                                                        +1
                                                                        Боюсь, что это тесты очень часто используются только из-за того, что в языке нет REPL. Последний сценарий, который я делал в REPL


                                                                        Боюсь, что подобные утверждения понижают мнение сообщества об уровне вашей квалификации. Очевидным (и основным) преимуществом Unit-тестирования является его автоматизм. То есть вы прогоняете Unit-тесты КАЖДЫЙ РАЗ, когда меняете что-то. Руками при этом ничего делать не нужно. И не должно быть нужно. Потому что руками вы можете не сделать, забыть, ошибиться… А компилятор не забудет и не пропустит тест (если, конечно, нерадивый разработчик сам его не отключит).

                                                                        Общее правило таково: если процесс разработки на 80% состоит из <какое-то простое действие>, значит вы что-то делаете не так.
                                                                          +1
                                                                          Спасибо за увлекательную лекцию про unit-тесты, а теперь покажите мне, где я утверждал, что они не нужны? Если вы дочитаете вот этот самый комментарий до конца, то, наверное, заметите, что его основной объект — REPL, и то, какие задачи с его помощью можно решать, в частности, интерактивная разработка и возможность видеть результаты каждого вызова (например, к стороннему API, который вы досконально ещё не знаете).

                                                                          В языках без REPL, таких как Java, аналогичные задачи приходится решать через подручные средства, например добавлением временного метода `main` или метода с аннотацией JUnit, который можно запустить тут же правой кнопкой мыши. Это криво, неудобно и занимает гораздо больше времени, но из доступных решений оно — самое простое.

                                                                          Каким образом фраза «тесты очень часто используются только из-за того, что в языке нет REPL» превратилась в головах некоторых читающих в «тесты не нужны, REPL их полностью заменяет» для меня непонятно. Ну ладно, будем считать, что это мой косяк и неудачно построенная фраза. Но после этой фразы идёт ещё с десяток моих комментариев (например, непосредственно следущий за тем, что вы процетировали), где я поясняю свою мысль, развеивая идею, что я каким-то образом почему-то против тестов. Но нет, вы, почему-то, предпочли пропустить всё это, и на основе одной неправильно понятой вами фразы сделать выводы о моей квалификации. Ура, товарищи, отличный вывод!
                                                                            –1
                                                                            В языках «таких как Java» не требуется добавлять временный метод main, так как достаточно проставить точку останова в нужное место и после этого ввести в Watch нужное вам выражение.

                                                                            Я ничего не пропускал, я ответил на вот это заявление:

                                                                            85% времени при разработке на Python я провожу в режиме «написать функцию -> проверить в REPL». Т.е. подавляющее большинство операций, которые я выполняю, напрямую связаны с переключением между текстовым редактором и REPL.


                                                                            Я никаких выводов не делал. Всего лишь указал вам на то, что считаю неверным и предупредил, что вас могут понять превратно.
                                                                              +1
                                                                              В языках «таких как Java» не требуется добавлять временный метод main, так как достаточно проставить точку останова в нужное место и после этого ввести в Watch нужное вам выражение.

                                                                              А теперь давайте поиском по странице найдём мой комментарий со словом «watch», в котором я подробно рассказываю, почему дебаггер + watch даже рядом не стоят с REPL.

                                                                              Я никаких выводов не делал. Всего лишь указал вам на то, что считаю неверным и предупредил, что вас могут понять превратно.

                                                                              Интересный у вас способ отреагировать на это заявление, если процитировали вы совершенно другое. Ну ладно, пусть будет по-вашему. Может быть у вас есть какие-то аргументы, почему вы считаете, что я на своём языке программирования делаю свои же задачи неправильно? Расскажите мне, пожалуйста, как мне правильно программировать на Python и самое главное почему?
                                                                                –1
                                                                                Расскажите мне, пожалуйста, как мне правильно программировать на Python и самое главное почему?


                                                                                Надеюсь, мое мнение вас не оскорбит. Но мне python не нравится совсем. И я вообще предпочитаю на нем не программировать. Это — уже совсем другой спор…

                                                                                Вы радуетесь в своем любимом языке вещам, которые меня в нем раздражают. А я, например, очень радуюсь, что в Java есть checked exceptions, которые вызывают недоумение у python-разработчиков (и не только у них). Это — тоже своего рода религия.

                                                                                Мой лучший друг — питонщик. Мы никогда не сможем в этом друг друга понять. Мировая наша с ним состоит в том, что питон удобен для маленьких программ, а Java — для больших. Это — единственный консенсус в области идеологии, которого мы смогли достигнуть.

                                                                                Боюсь, что это тесты очень часто используются только из-за того, что в языке нет REPL.

                                                                                Я вам процитировал эту фразу, потому что предыдущую вам процитировали выше. А так как я комментарии читал сверху вниз и отвечал последовательно, то, что вы писали ниже, я прочел позже.
                                                                                  +1
                                                                                  Надеюсь, мое мнение вас не оскорбит. Но мне python не нравится совсем. И я вообще предпочитаю на нем не программировать. Это — уже совсем другой спор…

                                                                                  Вот в следущий раз лучше сразу начинайте комментарий со слов «по-моему мнению», это снимет много вопросов.

                                                                                  Мировая наша с ним состоит в том, что питон удобен для маленьких программ, а Java — для больших.

                                                                                  Охх, как же уже надоели эти мифы...

                                                                                  А так как я комментарии читал сверху вниз и отвечал последовательно, то, что вы писали ниже, я прочел позже.

                                                                                  Т.е. вы сначала прочитали первое предложение, потом ответили, а потом дочитали комментарий? Окааай.
                                                                                    –2
                                                                                    А наличие крупных проектов на языке что-то говорит об удобстве написания оных на нём? Код ядра линукс тоже долгое время был на чистых сях, потом переехал на плюсы, если мне память не изменяет.
                                                                                      0
                                                                                      Код ядра линукс тоже долгое время был на чистых сях, потом переехал на плюсы, если мне память не изменяет.

                                                                                      Ага, аж на 0.6%.
                                                                                        +1
                                                                                        Ага, аж на 0.6%.

                                                                                        Хм, гитхаб почему-то считает все сишные хедеры написанными на языке с++…
                                                                                        +1
                                                                                        Код ядра линукс тоже долгое время был на чистых сях, потом переехал на плюсы, если мне память не изменяет.

                                                                                        Память вам изменяет. Линус ни за что не пустит плюсы в ядро.
                                                                                        Возможно, вы имели в виду GCC.
                                                                                        –3
                                                                                        YouTube — жуткая дрянь в плане надежности. Не думаю, что дело в том, на чем он написан. Но факт остается фактом. То стриминг глючит, то еще что-то…

                                                                                        Но комментатор ниже прав: наличие крупных проектов само по себе не доказывает, что язык для них пригоден. Вот, Facebook и Wikipedia вообще, прости господи, на PHP написаны. А работают. Но сколько же туда усилий и пота кровавого вложено…
                                                                                          +1
                                                                                          Естественно, все ж дураки, один вы знаете, как крупные проекты нужно писать.
                                                                                            0
                                                                                            Зато мы теперь знаем как их НЕ НУЖНО писать.

                                                                                            Крупные проекты это такая штука… никогда нельзя сказать насколько сложными они окажутся через пару лет используя конкретные технологии. А при неудачном выборе, попытка переписать на более подходящих технологиях аналогична разработке с нуля со всеми вытекающими.
                                                                                              0
                                                                                              Проблема роста проекта успешно решается через модульность уже много лет. Причём модульность в любом виде, так что даже проекты на C, в котором на уровне языка такого понятия нет, прекрасно растут просто за счёт правильной организации кода и инклюдов. Единственная проблема масштабируемости, которая зависит от языка и технологии, это проблема роста производительности. Но к организации кода она не имеет никакого отношения.
                                                                                              0
                                                                                              Причем тут я? Я участвовал в крупных проектах, которые писались хорошо. И участвовал в тех, которые писались плохо. И в том, и в другом случае я старался сделать лучше. Однажды мое нежелание делать дрянной код двигаясь на поводу у людей, не желающих думать в процессе разработки привело к тому, что я просто ушел из проекта. Потому что на мои попытки улучшить архитектуру архитекторы отвечали мне: «идея твоя хороша и верна, но мы ее не будем внедрять, так как в команде есть люди, которые ее не поймут». При этом и они, и я хорошо понимали, о ком именно идет речь.

                                                                                              О чем это я? О том, что 1000 обезьян может быть и не напишут «Войну и Мир» за год, стуча по машинкам, но зато они обойдутся фирме намного дешевле, чем 2-3 писателя. А разницы в готовом продукте всё равно никто не заметит, пока этот продукт — лидер и почти монополист. «Nothing personal, just business»
                                                                                                0
                                                                                                Не понял, какое отношение ваш комментарий имеет к вопросу удобства написания крупных проектов на разных языках?
                                                                                                  –1
                                                                                                  Вы меня обвинили в самоуверенности на основании моих чисто пользовательских наблюдений за YouTube. Я решил ответить на это заявление.

                                                                                                  Встречный вопрос: какое отношение имеет к качеству YouTube-а мое умение или неумение делать крупные проекты правильно? Я лишь указал, что приводить его в качестве примера удачи — неверно.
                                                                                                    0
                                                                                                    Вы меня обвинили в самоуверенности на основании моих чисто пользовательских наблюдений за YouTube.

                                                                                                    Я вам про YouTube вообще ничего не говорил, это вы почему-то выбрали из списка крупных проектов на Python тот, с которым у вас не сложилось, и на этом примере стали рассказывать про то, что одни языки предназначены для крупных проектов, а другие нет.

                                                                                                    А ответил я вам на вот это:

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


                                                                              +1
                                                                              Думаю, скорее, вместо «постоянной пересборки проекта в фоновом режиме» при написании программ на Java в IDE типа Eclipse. То же самое, только руками. И в эти «85% времени разработки» входит не только проверка в REPL, но и собственно написание функции.
                                                                                0
                                                                                Думаю, скорее, вместо «постоянной пересборки проекта в фоновом режиме» при написании программ на 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-тестами :)
                                                                                  –1
                                                                                  Из ваших слов создается впечатление, что главная проблема IDE для питона состоит в том, что ее нет… Вернее, в том, что она ужасно недоработана.

                                                                                  Позвольте, я вам «притчу» расскажу.

                                                                                  Есть такая компания — IBM. Гигантская, к слову, компания — что только ни производит, чем только ни занимается. И вот занялась она Джавой. Всерьез занялась, поскольку язык этот ей показался очень перспективным. Шел конец 90-х, Java-апплеты еще встречались на сайтах, а Java Enterprise еще только начинался и едва конкурировал с Perl-ом в папочке cgi-bin.

                                                                                  А IBM со свойственным им размахом начали чудовищного размера проект, писать который предстояло долго и упорно. Ну то есть сейчас он уже чудовищного размера. А тогда, ясное дело, только начинался.

                                                                                  И так как вложено в проект было очень много, им необходима была реально крутая отдача от разработчиков. И какой-то мудрый человек (увы, не знаю, как его звали) решил в 2001 году вложиться в создание крутой профессиональной Java IDE. Учитывая их бюджет, расходы на написание IDE были сущей мелочью — и они ее написали. Тяжелую и профессиональную, с высоким порогом вхождения и всеми необходимыми фичами. Написали не «за бабки», а «для себя» — и много лет вылизывали и тестировали этот JDT, будь он неладен. Сейчас он сияет и переливается. Уже года два не видел, чтобы eclipse в чистом java-проекте падал, если не прицеплять всякие левые JBoss-поделки. Завидная стабильность по сегодняшним временам!

                                                                                  И именно благодаря этому у джавистов сегодня есть эта замечательная штука — Eclipse. И, как мне кажется, это является главным критерием «зрелости» языка — если огромная компания готова создать мощную IDE для этого языка даже не на коммерческой основе, а так, как поделку, как побочный продукт своей технологии.

                                                                                  Надеюсь, что кто-нибудь и за python возьмется. И будет следующее (или даже это) поколение питонщиков с удивлением тут писать: как вообще можно код править в vim? Есть же «Pyclipse»!
                                                                                    +1
                                                                                    А хотите, я вам расскажу альтернативную притчу? C 91 по 95 год человек по имени Джейсм Гослинг работал над языком Oak в компании Sun Microsystems. Sun Microsystems на тот момент, вообще говоря, была не столько софтварной, сколько хардварной компанией, производящей большое разнообразие серверов, десктопных и микрокомпьютеров. Естественным желанием компании было найти общий знаменатель для всех своих систем. Отсюда и появился Java bytecode, а также знаменитый лозунг «write once, run anywhere».

                                                                                    В начале 2000х случился бум доткомов, тотальное распространение интернета и клиент-серверного ПО. Если есть потребность в программах, есть и потребность в разработчиках, способных их создавать. Проблема в том, что в тот момент достаточно квалифицированных разработчиков, способных писать на менстримовом C++ серверное ПО, которое бы не «текло» и не приводило к segfault-ам, было гораздо меньше, чем требовалось. Процесс обучения новых рекрутов был длительным и болезненным, поэтому нужно было снижать планку.

                                                                                    И вот тут Java выстрелила. В ней не нужно было следить за выделением и освобождением памяти, не нужно было учить 100500 замысловатых конструкций и концепций языка и даже исключения везде указывались явно, так что забыть их проверить было просто невозможно. Просто идеальный язык для толпы низкоквалифицированных недоспециалистов.

                                                                                    Но одной только смены языка недостаточно, чтобы успешно (с точки зрения дальнейшей продажи) писать большие проекты. Всё-таки нужны были тим лиды, простые правила, показывающие, как «правильно», и постоянный рефакторинг. Вручную перерефакторить говнокод, написанный толпой обезъянок, — та ещё работёнка. Поэтому нужны были средства для упрощения поиска нужных классов (из структуры директорий то непонятно, где что лежит), массового переименования (сразу то подумать как назвать переменную нельзя), вынесения методов в общий абстрактный класс (ведь простые правила, которые показал тимлид, в данном случае оказались слишком упрощёнными).

                                                                                    А как автоматизировать все эти задачи? Правильно, написать IDE, которая не заставит недоспециалистов писать хороший код, но позволит потом проще разгребать получившуюся кашу. И именно поэтому, как уже неоднократно замечали тут в комментариях, Java — это практически единственный язык, писать на котором без IDE просто невозможно.

                                                                                    Вся эта история, конечно, ложь и профанация — я за спиной у Гослинга и IBM не стоял, и как всё было на самом деле знать не могу. Но скажите, чем ваша история лучше?
                                                                                      +1
                                                                                      Кхм… т.е. на плюсах пишут только труъ-профи? ;)

                                                                                      «Поэтому нужны были средства для упрощения поиска нужных классов (из структуры директорий то непонятно, где что лежит)» — невозможно создать абсолютно продуманную структуру директорий + неймспейсы бывают очень полезны (но накладывают ограничение на модель хранения — ту самую структуру директорий). А если подключить ещё пару фреймворков и вспомнить огромное JDK — то даже на простом проекте без поиска приходится тяжеловато (все классы не запомнишь).

                                                                                      «массового переименования (сразу то подумать как назвать переменную нельзя)» — можно, но в процессе написания кода, бывает, приходит понимание более точного названия — вручную переименовывать?

                                                                                      «вынесения методов в общий абстрактный класс (ведь простые правила, которые показал тимлид, в данном случае оказались слишком упрощёнными)» — опять же в процессе разработки класс разрастается + появляются классы с похожим функционалом — вынести общее в общий абстрактный — вполне себе вариант. Или вы пишите только по заранее утверждённому ТЗ и в дальнейшем никогда не меняете код?

                                                                                      И да, вы ещё забыли кучу различных рефакторингов «вынести в метод», «вынести в переменную», «вынести в константу», «использовать интерфейс, где возможно» и прочие-прочие… Как вы смогли упустить такой пласт для отзывов об «обезъянках»?
                                                                                        +1
                                                                                        Кхм… т.е. на плюсах пишут только труъ-профи? ;)

                                                                                        Это значит, что на подготовку более или менее самостоятельного C++ разработчика уходит чертовски много времени.

                                                                                        А если подключить ещё пару фреймворков и вспомнить огромное JDK — то даже на простом проекте без поиска приходится тяжеловато (все классы не запомнишь).

                                                                                        Apache Spark — прекрасный пример, где структура директорий практически однозначно определяет местоположение какого-то куска кода. По сути, если пропустить общий для всех пакетов префикс «org.apache.spark», то получается практически двухуровневая иерархия — имя подпакета (например, «rdd», «storage», «scheduler») и дальше список файлов-классов.

                                                                                        можно, но в процессе написания кода, бывает, приходит понимание более точного названия — вручную переименовывать?

                                                                                        Внешний API модуля меняется редко, так что на практике даже ручное переименование не создаёт особых проблем. Т.е. фича полезная, но не критичная.

                                                                                        опять же в процессе разработки класс разрастается + появляются классы с похожим функционалом — вынести общее в общий абстрактный — вполне себе вариант.

                                                                                        Ctrl+X Ctrl+V раз в месяц — не проблема, проблема именно когда рефакторинг становится ежедневным и/или длительным процессом.

                                                                                        И да, вы ещё забыли кучу различных рефакторингов

                                                                                        Я ничего не забыл, но ведь и вы помните, что всё это спекуляция, и к реальности может не иметь никакого отношения?
                                                                                          0
                                                                                          «Внешний API модуля меняется редко, так что на практике даже ручное переименование не создаёт особых проблем. Т.е. фича полезная, но не критичная. „
                                                                                          Когда случается потребность (пусть и редкая) — становится очень даже критичной. Ну и для работы с внутренними переменными тоже бывает полезно

                                                                                          “Ctrl+X Ctrl+V раз в месяц — не проблема, проблема именно когда рефакторинг становится ежедневным и/или длительным процессом.»
                                                                                          Не проблема… но геморрой… Это как вместо cvs использовать бекапы — можно, но неудобно. Инструменты рефакторинга это делать аккуратнее, быстрее и с лучшим охватом мест использования (не приходится их искать).

                                                                                          «Я ничего не забыл, но ведь и вы помните, что всё это спекуляция, и к реальности может не иметь никакого отношения?»
                                                                                          Понимаю, но слишком уж максималитичо было сказано.
                                                                                            0
                                                                                            Когда случается потребность (пусть и редкая) — становится очень даже критичной. Ну и для работы с внутренними переменными тоже бывает полезно

                                                                                            Внутренние переменные прекрасно заменяются через string replace, так что это вообще не проблема. Для внешних вполне работает grep и sed. Но если это может делать IDE, то это несомненный плюс, тут не поспоришь. Однако я честно не думаю, что IDE для Java получили такое развитие только из-за необходимости время от времени переименовывать переменные.

                                                                                            Инструменты рефакторинга это делать аккуратнее, быстрее и с лучшим охватом мест использования (не приходится их искать).

                                                                                            Да ладно, что именно во внешних зависимостях поменяется, если вы часть методов вынесите из данного класса в его абстрактного предка?

                                                                                            Понимаю, но слишком уж максималитичо было сказано.

                                                                                            Я это к тому, что никогда нельзя делать однозначные заявления о том, почему и зачем что-то произошло. И никогда не стоит решать за других людей, как им удобней работать и какие инструменты для них важнее.
                                                                                        –1
                                                                                        Ваша история ничем не лучше моей. Но в ней-таки слишком много неоправданной злости. Даже хамства, я бы сказал.

                                                                                        Я сознательно перешел на Java с C++, уже имея весьма солидный опыт написания программ на нем. Потому что я, по вашему определению, «самоосознанная обезьянка».

                                                                                        1. Я считаю, что язык C++ образца 98 года ужасен, потому что не позволяет отделаться от кучи мелких ошибок. Даже опечатки в нем часто приводят к багам, над которыми приходится просидеть неделю. Попробуйте на досуге поиграть в «русскую рулетку» — найдите и удалите в большом проекте случайный символ "&". Язык, в котором подобной дряни не наблюдается, несомненно лучше. И для разработчиков, и для пользователей.

                                                                                        2. Я считаю, что регулярное переосмысление архитектуры проекта и последующий рефакторинг «говнокода» — неизбежная санитарная процедура. И если вы думаете, что лично вы не производите этот «говнокод» в промышленных масштабах, то смею вас заверить. Его производят абсолютно все, вне зависимости от языка и квалификации. С первого раза ни одна система не строится.

                                                                                        И, наконец:
                                                                                        3. Я убежден, что разработка ПО требует мышления в рамках некоторой выбранной парадигмы. И чем строже вы ограничиваете себя этой парадигмой (будь то ООП, ФП или даже АОП), тем качественнее ваш выхлоп. И, да, я предпочитаю, чтобы меня ограничивал компилятор, а системы статического анализа моего кода были встроены в тот текстовый редактор, в котором я этот код набираю и «били меня по башке» всякий раз, когда я пишу дрянь. Спортсмены вполсилы не играют даже с младшей сестренкой во дворе. Это расхолаживает.

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

                                                                                        Кстати, прекрасный пассаж:
                                                                                        В ней не нужно было следить за выделением и освобождением памяти, не нужно было учить 100500 замысловатых конструкций и концепций языка и даже исключения везде указывались явно, так что забыть их проверить было просто невозможно.


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

                                                                                        А во-вторых, посмотрите, как часто в вашем любимом проекте вылетают исключения, которые кто-то по ошибке забыл поймать. И подумайте, наконец, — друг вам тот, кто ваши ошибки помогает вытащить наружу, или враг.

                                                                                        Java — это практически единственный язык, писать на котором без IDE просто невозможно.


                                                                                        Неверное утверждение. И никто тут этого не писал. Верное утверждение такое:

                                                                                        Java — почти единственный язык, инфраструктура которого развита до такого высокого уровня, что ни один адекватный человек не станет работать отшельником хрен-пойми-в-чем, вместо использования нормального, специально предназначенного для Java инструмента.

                                                                                        Попробуйте — поймете.
                                                                                          +2
                                                                                          Потому что я, по вашему определению, «самоосознанная обезьянка».

                                                                                          Никаких определений я не давал.

                                                                                          Я считаю, что язык C++ образца 98 года ужасен

                                                                                          Да. И это никак не противоречит тому, что я написал.

                                                                                          Я считаю, что регулярное переосмысление архитектуры проекта и последующий рефакторинг «говнокода» — неизбежная санитарная процедура.

                                                                                          Рефакторинг — да, говнокода — нет. Достаточно освоить всего пару базовых принципов, чтобы свести 85% случаев рефакторинга к изменению внутри одного модуля.

                                                                                          Я убежден [...]

                                                                                          Вы правильно начали фразу, но не забывайте, что не все разделяют ваши убеждения.

                                                                                          Во-первых, потрудитесь почитать хоть что-то вот от этого господина, например. Вы поймете хотя бы приблизительно, какого уровня задачи решают «обезьянки» в своей повседневной работе.

                                                                                          Читал. И какого же уровня эти задачи?

                                                                                          А если хотите знать, что им приходится учить, то, например, вот.

                                                                                          Да, именно про них я и говорил. Это что-то меняет в моей фразе?

                                                                                          А во-вторых, посмотрите, как часто в вашем любимом проекте вылетают исключения, которые кто-то по ошибке забыл поймать.

                                                                                          Те, которое кто-то по ошибке забыл поймать — нечасто. Те, которые должны специально сломать стек и сигнализировать про исключительную ситуацию — чаще, и это хорошо.

                                                                                          Попробуйте — поймете.

                                                                                          Попробовать что? Я 5 лет писал на Java как на основном языке программирования. Работал и с IDEA, и с Eclipse, и с Netbeans и ещё с парой мнее известных IDE. Видел и энтерпрайз проекты, над которыми работали сотни разработчиков, и опен сорс решения, крутящиеся на сотне серверов. И видел как прекрасно растут системы, написанные на Java, Scala, Python, Erlang и десятке других языков, набираемых в IDEA, Vim, Emacs и просто в блокноте.
                                                                                            0
                                                                                            Ваши рассуждения в моем понимании совершенно не вяжутся с вашей квалификацией. После 5 лет в энтерпрайзе люди обычно не утверждают, что регулярный рефакторинг бывает нужен, чтобы «подчищать за обезьянками», а для создания качественного кода «достаточно понимать всего пару принципов». Может быть, я просто не дорос до вашего уровня. Допускаю. Или я вообще не понял, что вы имели в виду и нас унесло от изначальной темы.

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

                                                                                              Эх, ну вот опять вы читаете больше, чем написано… Ну да ладно, спор действительно пора заканчивать. Приятного вечера или что там сейчас в вашей временной зоне.
                                                                                      0
                                                                                      дебаггер не может сделать step back
                                                                                      Кстати, вот за это я их и не люблю. Особенно «весел» дебаггинг при отладке серверных систем, которые стартуют по 10 минут — приходится кучу раз делать запрос и кучу раз перестартовывать (по 10 минут каждый) чтобы выяснить причину. Был бы step back — цены бы такому дебаггеру не было.
                                                                                        0
                                                                                        Хм, банальный GDB, например, умеет делать reverse execution, но для этого его нужно запускать с логированием состояния.
                                                                                        0
                                                                                        Вообще такая «REPL-ориентированная» разработка напоминает разработку на форте из книжек по форту.
                                                                                  0
                                                                                  А можно пример IDE где удобно XML редактировать?
                                                                                  0
                                                                                  Новое название для Word-а IDE для написания служебных записок :)

                                                                                  А если серьезно, то вы абсолютно правы.
                                                                                  +19
                                                                                  Если какой-то спор идет десятилетиями, однозначного решения его не видно, и никто из противоборствующих сторон не раскаивается в своем выборе, то мы имеем дело с обыкновенной вкусовщиной. Но до чего же приятно доказать себе и другим, что именно твой способ делать что-то — самый правильный.
                                                                                    0
                                                                                    Стиль работы может быть очень разным как для разных ЯП, так и в пределах одного ЯП, но для разных задач.
                                                                                    • Для JavaScript в принципе не может существовать полноценной IDE, потому что JS — очень-очень динамический. Ни контекстные подскази толком не сделаешь (разве что вывалить все названия какие встречаются в коде), ни рефакторинги автоматизируешь, потому что без выполнения программы практически невозможно точно узнать что делает какой-то кусок кода. А с такими ограничениями от IDE толком ничего и не остаётся — подсветка, кнопки для запуска разных задач и получаем в итоге тот же Sublime.
                                                                                    • У всяких Java и C# таких ограничений почти нет (в C# такие есть динамические типы, но очень-очень не повсеместно). Поэтому и по коду прыгать удобно — всегда понятно откуда берётся какое-то имя, и рефакторинги замечательно работают, т.к. разночтений в принципе быть не может. В этом случае IDE даёт намного больше, чем в первом.
                                                                                      0
                                                                                      Продолжайте наблюдения.
                                                                                        0
                                                                                        Что-то не так с моим комментарием?
                                                                                          0
                                                                                          Я не понял какая связь между моим комментарием и вашим, поэтому подумал, что вы поделились своими наблюдениями, или, возможно, ошиблись веткой.
                                                                                            0
                                                                                            Нет, это моё мнение по поводу вашего «мы имеем дело с обыкновенной вкусовщиной». Вкусовщина безусловно имеет место, но она не на первом месте. На первом месте — специфика ЯП и техническая возможность сделать какие-то плюшки для него. Рассмотрены 2 условных семейства ЯП, показано, что «вкусовщина» более применима к JS и подобным (IDE почти равно редактору с плагинами), а для C#/Java редактором будет пользоваться только извращенец (IDE даёт очень многое).

                                                                                            Резюмируя: вкусовщина не на первом месте.
                                                                                              +1
                                                                                              А как вы объясните эту толпу извращенцев, которые вместо использования eclipse тащат его в vim и emacs? github.com/ervandew/eclim

                                                                                              Тут либо вкусы на первом месте, либо в редакторе удобней, чем в IDE.
                                                                                                +3
                                                                                                Хакерский романтизм и шило в заднице — не более.
                                                                                                  +2
                                                                                                  Весьма универсальный аргумент.
                                                                                                    +3
                                                                                                    Он здесь уместен. Есть программисты, которые просто работают за зарплату. Есть программисты, которым нравится работать круто — тренироваться делать фичи быстрее и качественнее. А есть программисты, которые любят возиться с инструментами надеясь, что как только оно заработает, качество их работы вырастет на порядок и вот тогда-то уж они запрограммируют всё-всё-всё.

                                                                                                    Та толпа извращенцев — из 3-ей категории.
                                                                                                      +1
                                                                                                      А мне кажется, что программист, который потянет проект уровня eclim должен быть достаточно умен для того, чтобы осознать, что его возня с редактором не дает должной отдачи.
                                                                                                        0
                                                                                                        Или у него просто идея-фикс: всё всегда редактировать только в Vim. Просто, Vim — это такая религия.
                                                                                                  +3
                                                                                                  vim и emacs уникальные редакторы. Подход к редактированию текста там радикально отличается от подхода к редактированию текста в блокноте. Большинство IDE это в общем блокнот обвешанный фичами. Редактировать текст там откровенно неудобно.

                                                                                                  Спор между IDE и vim с emacs это не спор между текстовыми редакторами и IDE. Это спор между разными подходами к редактированию текста. Если бы в IDE был нормальный текстовый редактор — адепты vim и emacs перешли бы на эту IDE не задумываясь.

                                                                                                  Поэтому и тащат eclipse в vim и emacs. Чтобы было нормальное редактирование текста плюс возможности IDE.
                                                                                          –1
                                                                                          Для JavaScript в принципе не может существовать полноценной IDE

                                                                                          С этой задачей вполне успешно справляется любой современный браузер. Там есть всё — и debug, и watch, и автодополнение, и даже измерение производительности.

                                                                                          без выполнения программы практически невозможно точно узнать что делает какой-то кусок кода

                                                                                          Это лишь означает, что язык — дрянь. Но всё, что можно было выжать (я выше перечислил), выжали. Это — уже больше, чем позволяла любая самая крутая IDE для C++ 15 лет назад.

                                                                                          в C# такие есть динамические типы

                                                                                          Это не мешает определить типы данных на этапе компиляции. А значит рефакторинг будет работать.
                                                                                        +6
                                                                                        Мне кажется, у вас либо мало опыта, либо просто какой-то bad luck с тем, что вы называете редактрами. Например:

                                                                                        Попробуйте, скажем, включить нумерацию строк в том же emacs!

                                                                                        Мне хватило 15 секунд, чтобы нагуглить, что нумерация строк включается командой `M-x linum-mode`. Хотя лично мне всегда хватало номера строки и колонки в статусной строке внизу активного окна. Подсказки и автодополнения зависят от мода — практически во всех специализированных модах, которые я использую — они есть. Поиск нужного файла тоже много где реализован, плюс, насколько я помню, доступен в виде отдельного мода (могу поискать, если хотите). Key bindings изменяются элементарно на что вам нравится через `(gloabl-set-key ...)` и `(local-set-key ...)`. Дебаггерами практически не пользуюсь, но гугль говорит, что их тоже не хватает.

                                                                                        Не могу говорить за все редакторы, но Emacs при желании — это не только IDE, но и практически полноценная операционная система, просто менее специализированная под конкретные языки, как Visual Studio или Eclipse.
                                                                                          –4
                                                                                          Вот именно — гуглится. Т.е. даже такую элементарную вещь включить без помощи гугла — никак. А что говорить о более сложных вещах?

                                                                                          Поиск файла — да. В том же projectile работает. Только я с ним 2 дня медитировал, пока разобрался со способами индексации и удалось получить приемлемую скорость работы этой функции.

                                                                                          Тем не менее, мне нравится с этим ковыряться — даже про lisp кое-что почитывать начал. Но не всегда есть время и желание гуглить 2 дня для добавления нужного функционала. Я поэтому пока с отладчиком в emacs и не связываюсь.

                                                                                          Emacs при желании — это не только IDE, но и практически полноценная операционная система

                                                                                          которой не хватает хорошего текстового редактора :)
                                                                                            +5
                                                                                            Вот именно — гуглится. Т.е. даже такую элементарную вещь включить без помощи гугла — никак. А что говорить о более сложных вещах?

                                                                                            Эмм… А как это должно было быть? Если гуглить — это, по-вашему, долго и сложно, то можно просто начать набирать `M-x line-...`, и Emacs вам сразу выдаст 2 режима для номера строк. Но всё-таки с гуглом удобней, как для Emacs, так и для IDE.

                                                                                            Поиск файла — да. В том же projectile работает. Только я с ним 2 дня медитировал, пока разобрался со способами индексации и удалось получить приемлемую скорость работы этой функции.

                                                                                            Опять же, за 30 секунд нагуглил родную функцию `locate`, которая находит файл внутри какой-то директории. Загуглил — потому что для того же Python у меня автоматически включается умная подстановка пути по `C-x f`.

                                                                                            которой не хватает хорошего текстового редактора :)

                                                                                            Старая и несправедливая шутка :) Emacs — это непривычный текстовый редактор, да, но плохим его назвать точно нельзя.
                                                                                              –1
                                                                                              Если гуглить — это, по-вашему, долго и сложно, то можно просто начать набирать `M-x line-...`,

                                                                                              Это не «сложно и долго». Это — излишне сложно и долго. Зачем мне вообще знать эту команду? Почему не мышкой? Нет, я понимаю, конечно, почему в emacs-е это так. Но это же является недостатком для промышленного использования — слишком сложно.

                                                                                              Emacs — это непривычный текстовый редактор, да, но плохим его назвать точно нельзя.

                                                                                              От org-mode я вообще в восторге!
                                                                                                +1
                                                                                                Это не «сложно и долго». Это — излишне сложно и долго. Зачем мне вообще знать эту команду? Почему не мышкой? Нет, я понимаю, конечно, почему в emacs-е это так. Но это же является недостатком для промышленного использования — слишком сложно.

                                                                                                15 секунд и гугль раз в жизни — это слишком сложно? Ммм…
                                                                                                  0
                                                                                                  При таком раскладе гуглопоиск должен быть встроен в emacs из коробки.
                                                                                                    0
                                                                                                    Зачем?

                                                                                                    Впрочем, если хочется, функцию для этого написать недолго.
                                                                                                      +2
                                                                                                      В общем-то вся ирония как раз в том, что не хочется.
                                                                                                      0
                                                                                                      Не из коробки, но идея интересная, и кому-то она в голову уже пришла. Особенно интересной кажется вариация с шорткатом для поиска по сообщениям об ошибках.
                                                                                                    +4
                                                                                                    Это не «сложно и долго». Это — излишне сложно и долго

                                                                                                    А программировать вы тоже начали методом тыка, или все же прочли пару мануальчиков?
                                                                                                      0
                                                                                                      С каких это пор программирование и использование программ — равносильные понятия?
                                                                                                        0
                                                                                                        С тех пор, с каких для эффективной работы нужно уметь пользоваться инструментами. Как считаете, можно быть хорошим столяром, не умея пользоваться молотком?
                                                                                                          –1
                                                                                                          Не помню, чтобы мне приходилось гуглить, чтобы научиться пользоваться молотком. Или изучать устройство молотка. Или подготавливать специальным образом руки к работе с молотком. Выше ключевое слово — «излишне».
                                                                                                            0
                                                                                                            Вы уверены, что учились пользоваться молотком «без гугла», т.е. абсолютно самостоятельно, извлекая информацию об этом деле только из молотка, досок и гвоздей? Ни разу даже не видели, как их забивает кто-нибудь более опытный, прежде чем первый раз попробовать самому?
                                                                                                              0
                                                                                                              Видел, конечно. И этой информации хватило.
                                                                                                                0
                                                                                                                ЧТД. А если смотреть, как кто-нибудь работает с Emacs, Visual Studio или Photoshop — те функции, которыми они активно пользовались, гуглить, вероятно, тоже не понадобится. Но, да, смотреть придётся более внимательно, к молотку наше подсознание эволюция лучше подготовила, чем к мэйнстримным устройствам управления компьютером.
                                                                                                              –1
                                                                                                              Возможно вы не поняли, но «молоток» в моем примере, это лишь абстракция, обозначающая инструмент мастера. Замените «молоток» в вашей голове на фрезерный станок TF 200 SE.
                                                                                                        +2
                                                                                                        Почему не мышкой?

                                                                                                        Мышкой куда? Попробовал включить в PyCharm те же самые номера строк, без гугла не осилил. А M-x line-<TAB> — вероятно, догадался бы. Впрочем, существенным недостатком PyCharm это не считаю, потому как гугл — это несложно и недолго.
                                                                                                          0
                                                                                                          Два раза shift или ctrl+shift+a и там можно искать интересующее. Например, show numbers.
                                                                                                            0
                                                                                                            О, спасибо. Вот что в меню Navigate перечислены не все команды поиска, а к невзрачной серой лупе на тулбаре стоит присмотреться отдельно, я и не догадался. И инструкцию не прочёл — кажется, в этом треде не зазорно в таком признаться.

                                                                                                            Но, чёрт возьми, это же прямо супермаркет какой-то: самый ходовой товар — не на полке с аналогичными, а на другом конце зала.
                                                                                                              0
                                                                                                              Но, чёрт возьми, это же прямо супермаркет какой-то: самый ходовой товар — не на полке с аналогичными, а на другом конце зала.

                                                                                                              Не соглашусь. В 9х% случаев знаешь где искать (в именах файлов, в текущем файле, в именах опций, ect) и вызываешь соответствующий шорткат. Дабл шифт лично я использую крайне редко. Когда действительно не понятно, «куды бечь».
                                                                                                            +1
                                                                                                            В Android Studio ПКМ по месту, где должны быть номера, Show line numbers. Зачем там нужен был гугл, непонятно.
                                                                                                        0
                                                                                                        [irony] EvilMode добавляет нормальный редактор [/irony]
                                                                                                          +3
                                                                                                          Просто воспринимайте емакс как конструктор текстового редактора. И если вам некогда возиться с конструктором, то логично использовать IDE. Но если вы emacs до сих пор не выкинули, то вы подружитесь, пусть и через пару лет.
                                                                                                            0
                                                                                                            Просто воспринимайте емакс как конструктор текстового редактора. И если вам некогда возиться с конструктором, то логично использовать IDE.


                                                                                                            Я наверно совсем не труЪ emacs-пользователь, но в целом я поднастроил себе редактор всего за месяц… с тех пор фундаментальных изменений больше не вносил и мне моего конфига вполне хватает) Правда пришлось смириться с тем, что некоторые иногда удобные фичи в emacs настроить нельзя.
                                                                                                              0
                                                                                                              Вы счастливый человек, а я все думаю спустя 10 лет пользования emacs что еще можно утянуть себе из melpa.
                                                                                                                0
                                                                                                                У меня единственное чего не хватает в конфиге, так это автокомплита с семантическим дополнением и переходы к определению/реализации, но эти фичи впринципе качественно не настраиваются в emacs, т.ч. я смирился)
                                                                                                                0
                                                                                                                я поднастроил себе редактор всего за месяц


                                                                                                                Всего… за месяц

                                                                                                                Вы знаете, я, конечно, не скажу за вас — не знаю, что вы там делаете в нем и какие тонкости решаете, но когда я настраивал себе eclipse, чтобы он нормально код форматировал (не переносил 81-й символ на новую строку и т п...) и немного хоткеи менял, а потом конфигурил в нем проектный файл для C++-проекта, то на всё ушло пара часов и мне это показалось очень долго.
                                                                                                                  +1
                                                                                                                  1) Месяц настройки — это н значит, что я месяц настраивал редактор прежде, чем начал им пользоваться. Это значит, что я все свои хотелки добавлял по мере надобности в течении примерно месяца)

                                                                                                                  2) Вот конкретно eclipse я несколько раз пробовал использовать, и всегда он мне казался каким-то неудобным и нелогичным. До emacs я исопльзовал QtCreator, который меня устраивал всем, кроме того, что в нем нельзя было работать без использования мыши. Собственно из-за этого я и перешел с него на emacs и даже несмотря на отсутствие некоторых фич, которые были в креэйторе, работа в emacs все равно оказалась удобней.
                                                                                                                    –1
                                                                                                                    Eclipse мне тоже поначалу показался нелогичным. Просто, у него довольно высокий «порог вхождения». Он на первом же уровне формирует у пользователя нетривиальные понятия типа workspace, debug configuration и прочее. Но зато как только вы поймете смысл всего этого, вы увидите четкую структурированность и железную логичность архитектуры. В Idea, на первый взгляд, более логичную, многие фичи прикручены в весьма странных местах в угоду новичкам, которые не желают привыкнуть к идеологии системы. Так как я всё всегда изучаю «от устройства к внешнему виду», мне eclipse ближе. Но на emacs я, всё же, не согласен.
                                                                                                                      +2
                                                                                                                      В Eclipse нет ничего нетривиального, там есть нелогичное. И разница в том, что к eclipse нужно «привыкать к идеалогии системы», а в emacs все настраивается по своему вкусу.
                                                                                                                        –1
                                                                                                                        Что вам там показалось нелогичным? Мне правда интересно. Просто хотя бы какой-то конкретный пример.

                                                                                                                        Мне, на самом деле, Emacs вообще не кажется конкурентом eclipse-а в плане работы с Java кодом. Слишком несопоставимые возможности.

                                                                                                                        И я считаю, что если на данном этапе какая-то IDE для своего языка сопоставима по возможностям с Vim и Emacs, то она попросту недоделана.
                                                                                                                          +1
                                                                                                                          Я последний раз Eclipse открывал года 3-4 назад, т.ч. конкретных примеров сейчас назвать не смогу. Ну и да. я её не для Java, а для C++ использовал.
                                                                                                                            0
                                                                                                                            Для работы с C++ Eclipse необходимо настраивать. Увы, CDT при всей своей универсальности далек от совершенства. Но при этом я не знаю ни одной другой среды, настолько всеядной в плане парадигм и компиляторов. Хотите mingw? Окей. Хотите MS C++? Без проблем. Хотите makefile? Вам сгенерировать? Или свой подложите? Хотите кросс-платформенное приложение одновременно на C, Java и Фортране? Да пожалуйста! Только 3 плагина поставьте в среду, да настроечки пропишите. И будет вам во всех трех языках intellisense.

                                                                                                                            Вы знаете, что меня раздражает в Eclipse на данный момент? То, что Ctrl+Click по декларации native-функции в Java не вызывает имплементацию этой функции в JNI-слое на C. И, да, я считаю, что это из разряда «мелких бриллиантов»
                                                                                                                              +1
                                                                                                                              Ну практически весь функционал Elipse+CDT перекрывается QtCreator'ом, который для C++ из коробки лучше приспособлен. Ну а emacs разве что inetllisense по нормальному не умеет из всего этого)