С тех пор, как я начал заниматься программированием, этот вопрос не даёт мне покоя, а многочисленные темы на форумах и хабре ясности не внесли. Плюс к этому, мне кажется, некоторые аргументы как за одну, так и за другую сторону не были приведены. А у тех, что приведены, неверно расставлены приоритеты и упущен контекст.
В статье я постараюсь исправить это упущение и расставить ещё немного точек над «ё».
Приглашаю всех поучавствовать в поисках идеального инструмента.
О моём опыте
Программировать я начинал ещё в ДОС. на 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)
maroziza
20.08.2015 22:52+21Я считаю что есть только один критерий оценки — время жизни. Если в редакторе и ИДЕ одинаковый результат получается за разное время, то победитель тот, у кого это время ниже. И ИДЕ значительно чаще дает этот выигрышь по времени. Ничего не ценно так, как время разработки (опять же, при всех остальных прочих равных, подразумевается что код на выходе идентичный). Даже самая последняя ИДЕЯ и Вебшторм на многомегабайтных проектах запускается за 5 секунд на далеко не свежем компьютере, а если это не так, ну это же ваш рабочий инструмент, вы им зарабатываете деньги и не можете обеспечить себе комфортное рабочее место?
А про поддержку CSV, XML, и тд в ИДЕ это вообще отдельная история. ИДЕ не только обычно поддерживают их лучше, но и понимают семантику, могут поставить перекрестные ссылки и дополнять нужные ключи, как например .properties в java или свякзки angular.js и HTML, все это гарантированно экономит время, и вспоминания, и навигации.
Практически единственный момент (который тоже не всегда применим), это когда необходимо поменять что-то на уже рабочем сервере. Но для многих языков это невозможно — нужна перекомпиляция, или подход с деплоем не позволяет так просто пойти на сервер и менять файлы. В остальных всех случаях у редакторов нет никаких шансов перед ИДЕ (стоимость не берем во внимание).
Кроме того, ИДЕ это просто продолжение идеи редактора, а не паралельная ветвь эволюции. Ведь редактор с пониманием семантики русского языка становиться сразу же ИДЕ русского языка. Почему бы им не пользоваться при наличии?Pilat
20.08.2015 23:19Без редактора тоже не очень хорошо. IDE не сильно заточены, к примеру, для открытия огромных файлов.
MaximChistov
21.08.2015 00:00Идея на работке спокойно открывает файлы в 6к+ строк, работает мгновенно, навигация мгновенная
zzashpaupat
21.08.2015 00:42Огромные файлы — это 100 мегабайт, 1200 мегабайт. Всякие CSV, XML выгружаемые.
Вот тут-то уже IDEA не справится. И Atom, и Sublime тоже спасуют. Только vim и спасает в таких случаях.
js605451
21.08.2015 01:02+6ИМХО, файлы такого размера не открывать надо, а запросы по ним гонять через всякие grep, а лучше — через инструменты, предназначенные для этих конкретных файлов. Слабо себе представляю что вменяемого можно сделать открыв 100-мегабайтный текстовый файл.
Delphinum
21.08.2015 02:21Как то на работу принесли огромедный файл выгрузки из одной известной системы похозяйственного учета. Содержимое этого файла было нам не известно, но его нужно было подготовить к загрузке в базу данных. Как вы бы предложили «гонять по нему через всякие grep» даже не взглянув на содержимое?
js605451
21.08.2015 03:01+7head -n20 ogromenny.txt
Delphinum
21.08.2015 03:48+2неа, там все в 1 строку. XML знаете ли. Да и первые хз сколько байт там были заполнены не нужной нам в базе инфой.
kiba
21.08.2015 07:42+14~$ xmllint --format --recover ogromenny.xml 2>/dev/null | head -n20
Delphinum
21.08.2015 23:44А чем хуже: vim ogromenny.xml — ?
bigfatbrowncat
22.08.2015 03:00А зачем вообще его читать в текстовом редакторе? Загрузите его сразу Xml-парсером любимого языка. Скажем, я бы открыл его парсером Java. А потом включил режим отладки и в окошке Watch (слыхали?) писал бы запросы на вложенные конструкции, изучал бы семантику, правил код чтения… что там вы собирались вообще с этим XML делать?
На кой черт мне XML самому глазами парсить?Delphinum
22.08.2015 11:18А ничего, что вы его еще в глаза не видели и не знаете, есть ли там данные для загрузки в базу или нет? Или вы сначала попробуете программу загрузки написать, а уже когда поймете, что там не XML, а бинарник, решите остановится? )))
bigfatbrowncat
23.08.2015 09:32Хм… я так понял, что речь именно про XML. Ну да ладно.
На самом деле, я просто считаю, что способность открывать текстовым редактором файлы по 100 мегабайт — вещь во-первых редко используемая в реальной жизни, а во-вторых, не входящая в спектр первой необходимости для IDE. С этим, конечно, vim справится лучше (он же писался для терминалов, где пропускная способность канала до сервера была сопоставима со скоростью набора текста). Но при сегодняшних объемах оперативной памяти… В общем, любой простой редактор это может. И многие не тормозят при этом. TextWrangler, например. Ну, сожрет он эти 100 мегов из памяти — ну и черт с ним.Delphinum
23.08.2015 11:45+1Да, так и есть. Просто когда вы пользуете Vim для написания программ, а затем его же для других, околопрограммистских действий, это довольно удобно.
kiba
24.08.2015 02:26отсутствие автоформатирования xml из коробки.
но, по правде признаться, код выше я как раз и выдрал из своего .vimrc, в котором и исправляется этот досадный недостаток =)
au FileType xml exe ":silent 1,$!xmllint --format --recover - 2>/dev/null"
Flammar
21.08.2015 03:03+3Для предварительного взгляда на содержимое использую FAR. И вообще использую его как основной файловый менеджер.
MaximChistov
21.08.2015 12:18+1ide для кода, а не для жирных файлов данных, внезапно!
ffriend
21.08.2015 12:35Я тут как сторонний наблюдатель, но вроде как речь именно о том, что IDE не для всего хорошо подходит, и на задаче открытия жирных файлов данных лучше ведут себя редакторы.
Вопрос не по теме, но очень любопытно: а что у вас в файле на 6к+ строк? Это же реально много :)MaximChistov
21.08.2015 12:36Легаси там. Суммарно несколько миллионов строк в проекте, не один десяток файлов в 1к+ строк
roman_kashitsyn
21.08.2015 12:45В файле с юнит-тестами
clang-formatболее 10к строк кода (clang/unittests/Format/FormatTest.cpp). Там даже Emacs иногда притормаживает :)
webkumo
21.08.2015 15:44Редакторы для открытия файлов данных? Обычно такие файлы открываются для изучения, а не изменения (а за изменения в авто-генерируемых файлах надо давать по рукам!) — там простого просмотровщика хватит.
ffriend
21.08.2015 17:27Мне тут на прошлой неделе прислали SQL дамп с лишними символами вначале файла, мол, ты ж инженер, сам разберёшься.
В любом случае, если есть инструмент, не вижу смысла его не использовать.webkumo
21.08.2015 19:50Редакторы любят загружать значительный кусок/весь файл в память, всяческие вьюеры стараются не кэшировать такие размеры, а читать по мере надобности…
ffriend
21.08.2015 20:36Так какое решение для ситуации с побитым SQL дампом вы предлагаете?
webkumo
21.08.2015 20:58Это печально, когда складывается ситуация, когда _надо_ подредактировать генерируемый файл данных. Вообще это ставит под сомнение валидность данных вообще (а не только в начале файла).
Поэтому я стараюсь таких ситуаций избегать… Если всё-же приходится — беру простейший, без обвеса редактор и им правлю — такие редакторы не стараются закешировать всё что надо и что не надо.ffriend
21.08.2015 21:39Ну т.е. в итоге всё равно приходим к задачам, с которыми IDE справляются плохо :) Это не значит, что использовать IDE плохо — большинство задач не включают в себя редактирование больших файлов — но это отвечает на вопрос, когда редактор лучше IDE.
Alexeyslav
24.08.2015 10:33Когда-то давным-давно была написана утилитка, которая при помощи простых инструкций могла собирать файл из разных кусочков. Как раз для таких случаев, когда во время дискет была необходимость править 1-2 байта в файлах по 100Мб которые тогда не открывались ни в одном редакторе.
Думаю такую программу можно набросать на любом языке под конкретную однократную задачу.
bigfatbrowncat
22.08.2015 03:01Откройте исходный код какого-нибудь парсера. Или какой-нибудь контроллер серьезного серверного приложения. Мало ли…
ffriend
20.08.2015 23:43+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 строк и увидеть результат всех выражений.
Я не знаю, насколько распространён такой подход (да и мне, по большому счёту, всё равно), но для меня «редактор» даёт существенный прирост скорости разработки, а никак не её уменьшение.
Desiderata
21.08.2015 00:47Документация говорит, что достаточно выделить и нажать ALT+SHIFT+E.
В другом месте документации правдо сказано, что нажимать надо ALT+SHIFT+I.
Но так или иначе для этого есть сочетание кнопок.ffriend
21.08.2015 01:09+2Для того, чтобы отправить выделенное — да, наверняка. А чтобы отправить текущую строку? А текущее определение? А если кроме Python вы иногда пишете на Ruby, Clojure или Julia? Я могу вам привести две страницы примеров, когда Emacs значительно ускоряет разработку по сравнению с традиционными IDE. IDE заточены под определённый, достаточно узкий круг задач и возможностей. Редакторы более широкого профиля (а это, кроме Vim и Emacs, также Sublime Text, Atom, LightTable и другие) предоставляют из коробки только основные фичи, но практически неограниченные возможности через расширения. Говорить, что одно в принципе лучше, чем другое — это как-то странно.
zzashpaupat
21.08.2015 00:51Выделяете кусок кода (удобнее всего с помощью Ctrl+W инкрементально выделять), затем Alt+Shift+E и код будет исполнен. И в PyCharm (как и любой другой IDE на основе IDEA) можно практически на любое действие навесить хоткей.
ffriend
21.08.2015 01:36+1А создать действие «выделить текущую строку и отправить её в REPL» можно?
Miklos
21.08.2015 01:42Можно макрос записать и забиндить его на кнопку.
ffriend
21.08.2015 02:30+1Может быть я не слишком изощрён в записывании макросов в IDEA, но простой макрос «перейти в конец строки, выделить всё до начала строки, нажать Alt+Shift+E» у меня получился довольно кривой: первые пару строк посылает нормально, потом сбивается. Почему сбивается — непонятно, ибо всё, что у меня есть — визуальное отображение действий, что там происходит внутри я не знаю.
Так или иначе, я могу очень просто усложнить задачу. Как я уже говорил выше, достаточно попробовать отправить в REPL всё выражение (например, функцию). Или открыть в бразере страницу из документации по текущей функции. Или автоматически найти и перейти в корень проекта. Или переключаться по одной горячей клавише между редактором и REPL-ом. Или сделать что угодно из этого удалённо по SSH.
Именно такие кастомизации делают программируемые редакторы такими крутыми, и позволяя автоматизировать любые рутинные действия, какими бы сложными они ни были.bigfatbrowncat
22.08.2015 03:06Я вам сейчас целый мир открою:
www.jetbrains.org/intellij/sdk/docs
С помощью вот этого великого знания вы можете добавить к IDEA абсолютно любую фичу. Вот прям совсем-совсем. Вплоть до поддержки нового языка, компилятор ккоторому накодили под пивко на выходных. А уж взять код имеющегося плагина (если он open-source) и добавить в него простую фичу — это вообще час-два работы.ffriend
22.08.2015 16:26+1А уж взять код имеющегося плагина (если он open-source) и добавить в него простую фичу — это вообще час-два работы.
Час-два работы — это круто. Последнюю фичу в Emacs — переключение на консоль и переход в конец буфера — я написал примерно за 10 минут. Вы бы как раз к этому моменту докачали код плагина и открыли проект.
И давайте на чистоту: как много пользователей IDEA пишут для неё плагины? Для пользователей Emacs это обычные и даже немного рутинное дело.Miklos
22.08.2015 21:37У пользователей IDEA всё из коробки есть. Если нет силько кастомных фич, то или смериться, или писать плагин. Тут идеология совершенно другая: за деньги тебе дают готовый к использованию продукт.
bigfatbrowncat
23.08.2015 09:36Последнюю фичу в Emacs — переключение на консоль и переход в конец буфера — я написал примерно за 10 минут
Вот тут-то и кроется ключевая разница между вашим подходом и моим. Я оценил время, требуемое на внедрение и тестирование фичи (просто по привычке — я уже лет пять это делаю регулярно), а вы, очевидно, написали, сколько времени будете вводить код плагина.
И, да, вы правы. Пользователи Eclipse в среднем пишут плагины довольно редко — за них это сделали профессиональные писатели Eclipse-плагинов.ffriend
23.08.2015 14:32а вы, очевидно, написали, сколько времени будете вводить код плагина.
Нет, я написал полное время разработки — от появления необходимости, до готовой к использованию фичи.bigfatbrowncat
23.08.2015 16:04На каком это языке?
ffriend
23.08.2015 16:18+1Emacs Lisp, вестимо.
Вам бы почитать, что из себя представляет init.el, и как его можно использовать для кастомизации редактора.bigfatbrowncat
23.08.2015 19:51-1Я lisp действительно не знаю. Просто интересно было оценить объем требуемого кода. В любом случае смысла большого в этом нет. Просто полюбопытствовал. Я сам 10 минут бы только разбирался в том, как писать эти расширения. Разумеется, пользоваться средой, в которой навык написания расширений входит в базовый набор навыков для ее использования, я бы не стал. Даже Linux на десктопе сейчас уже ушел от подобного уровня недоработанности.
ffriend
23.08.2015 19:58+1Разумеется, пользоваться средой, в которой навык написания расширений входит в базовый набор навыков для ее использования, я бы не стал.
Не входит, пользуйтесь на здоровье базовой версией.
zzashpaupat
21.08.2015 12:13С точки зрения IDEA — это 2 разных действия, одним хоткеем не получится, к сожалению. Но можно, как написали выше, сделать макрос.
В настройках можно сделать хоткей на выделение всей строки: Select Line at Caret.
P.S. Я почти всегда пользуюсь Ctrl+W — это очень удобно.
js605451
21.08.2015 01:04+885% времени при разработке на Python я провожу в режиме «написать функцию -> проверить в REPL». Т.е. подавляющее большинство операций, которые я выполняю, напрямую связаны с переключением между текстовым редактором и REPL.
У вас это вместо тестов чтоли? Не могу представить зачем это может быть нужно глядя на ваше «85% времени разработки».ffriend
21.08.2015 01:29-8Боюсь, что это тесты очень часто используются только из-за того, что в языке нет REPL. Последний сценарий, который я делал в REPL:
1. Создать объект, открывающий соединение с БД.
2. Вызвать несколько методов.
3. Посмотреть, что изменилось в БД, проверить логику.
4. Загрузить датасет с подозрительными результатами, преобразовывая каждую запись к объекту модели.
5. Найти ошибку.
REPL, правда, Scala-овский, в нём заменять определения на лету достаточно тяжело, поэтому пофиксить ошибку на лету не получилось. Но сценарий явно не подпадает под определение «вместо тестов».js605451
21.08.2015 01:39Я искренне не понимаю что вы с этими REPL'ами делаете. Как вы определяете, что остальной код не сломался из-за ваших правок? Тоже REPL руками? Перед каждым коммитом?
ffriend
21.08.2015 01:45Вы путате тёплое с мягким. Если вам нужны регрессионные тесты, вы пишете тесты. Если вам нужна интерактивная разработка, вы используете REPL. Если у вас нет REPL, тогда да, в некоторых сценариях вы можете заменить его REPL-ом и гонять небольшие куски кода прямо из IDE. Но, как я уже показал выше, работает это далеко не всегда.
js605451
21.08.2015 02:35+5Не уверен что с чем я путаю, но ваш подход очень напоминает подход начинающих — когда пишется маленькая демо-программка, которая воспроизводит интересующий сценарий, а после этого благополучно удаляется. Разница между такой программкой и тестом только в том, что тест в итоге остаётся.
ffriend
21.08.2015 02:54Ок, пример с БД, где мне нужно интерактивно исследовать поведение системы, вас не впечатлил. Попробуем по-другому.
Прямо сейчас у меня открыт код классификатора изображений. Суть моей работы состоит в исследовании, какие преобразования над изображением и какие параметры классификатора дают оптимальный результат. В начале работы я загружаю весь набор изображений в память, что занимает примерно 2 минуты. Затем я беру какое-нибудь изображение и начинаю применять к нему фильтры, пытаясь определить, какой из них даст нужные мне признаки. При этом каждый раз я вызываю в REPL функцию применения фильтра и отображения результата на экран.
После того, как я подобрал фильтр-кандидат, я обучаю и кросс-валидирую классификатор-кандидат, что занимает около 1.5 минут. В зависимости от результатов классификатора, я принимаю решение, заменить ли классификатор, заменить ли фильтр, заменить ли их параметры и если да, то на какие.
Каждый следущий шаг зависит от результатов предыдущего. И каждый шаг занимает определенное количество времени, поэтому перезапускать всё сначала и терять, например, уже обученный классификатор — неприемлимая потеря времени. REPL позволяет поддерживать такую разработку. Скажите, как юнит-тесты помогут мне в этой задаче?js605451
21.08.2015 03:14+3как юнит-тесты помогут мне в этой задаче?
Никак. Вы прыгнули с задачи про «соединение с БД и поиск ошибки» на задачу а-ля матлаб.
Давайте теперь предположим, что вы дошли до 10-го шага, когда должны получиться там какие-то финальные результаты, но получается полная хрень. И тут вы осознаёте, что ошибка была где-то на шаге 3. Будь это отдельный скрипт — открыли, поправили, запустили и пошли пить кофе. В вашем же случае нужно участие человека.
А теперь давайте предположим, что к вам в команду пришёл новый сотрудник Вася и просит поделиться с ним вашими наработками. Вы ему дамп процесса python снимете и попросите восстановить на его машине? Попутно рассказывая, что первый шаг это 8 раз вверх, второй — 6, а если 4 вверх, то там ошибка, и результаты никуда не пошли?ffriend
21.08.2015 03:29Никак. Вы прыгнули с задачи про «соединение с БД и поиск ошибки» на задачу а-ля матлаб.
Задача про БД ничем принципиально не отличается от задачи «а-ля матлаб» — и там, и там у вас есть данные и/или функции, которые нужно исследовать и в зависимости от результата решить, что делать дальше. Я вам могу ещё с десяток таких же примеров привести, начиная от работы со сторонними API и заканчивая зажиганием лампочек на Raspberry Pi, где интерактивная консоль экономит уйму времени при разработке. «При разработке» здесь ключевое слово.
Давайте теперь предположим, что вы дошли до 10-го шага, когда должны получиться там какие-то финальные результаты, но получается полная хрень. И тут вы осознаёте, что ошибка была где-то на шаге 3. Будь это отдельный скрипт — открыли, поправили, запустили и пошли пить кофе. В вашем же случае нужно участие человека.
А кто вам запрещает иметь рядом скрипт? Собственно, я ещё в самом первом комментарии написал:
В Emacs у меня обычно открыто 2 буффера — один для кода, а второй с REPL.
Вы пишете программу как обычно, оформляете в такие же функции и модули, пользуетесь подсветкой синтаксиса и автодополнением, только плюс к этому у вас ещё есть интерактивная консоль, где любую функцию можно попробовать напрямую.
А теперь давайте предположим, что к вам в команду пришёл новый сотрудник Вася и просит поделиться с ним вашими наработками. Вы ему дамп процесса python снимете и попросите восстановить на его машине? Попутно рассказывая, что первый шаг это 8 раз вверх, второй — 6, а если 4 вверх, то там ошибка, и результаты никуда не пошли?
Аналогично, Вася получит кодовую базу, ничем не отличающуюся от той, что кто-нибудь мог бы сделать в PyCharm и/или без REPL.
bigfatbrowncat
22.08.2015 03:09+1Боюсь, что это тесты очень часто используются только из-за того, что в языке нет REPL. Последний сценарий, который я делал в REPL
Боюсь, что подобные утверждения понижают мнение сообщества об уровне вашей квалификации. Очевидным (и основным) преимуществом Unit-тестирования является его автоматизм. То есть вы прогоняете Unit-тесты КАЖДЫЙ РАЗ, когда меняете что-то. Руками при этом ничего делать не нужно. И не должно быть нужно. Потому что руками вы можете не сделать, забыть, ошибиться… А компилятор не забудет и не пропустит тест (если, конечно, нерадивый разработчик сам его не отключит).
Общее правило таково: если процесс разработки на 80% состоит из <какое-то простое действие>, значит вы что-то делаете не так.ffriend
22.08.2015 04:11+1Спасибо за увлекательную лекцию про unit-тесты, а теперь покажите мне, где я утверждал, что они не нужны? Если вы дочитаете вот этот самый комментарий до конца, то, наверное, заметите, что его основной объект — REPL, и то, какие задачи с его помощью можно решать, в частности, интерактивная разработка и возможность видеть результаты каждого вызова (например, к стороннему API, который вы досконально ещё не знаете).
В языках без REPL, таких как Java, аналогичные задачи приходится решать через подручные средства, например добавлением временного метода `main` или метода с аннотацией JUnit, который можно запустить тут же правой кнопкой мыши. Это криво, неудобно и занимает гораздо больше времени, но из доступных решений оно — самое простое.
Каким образом фраза «тесты очень часто используются только из-за того, что в языке нет REPL» превратилась в головах некоторых читающих в «тесты не нужны, REPL их полностью заменяет» для меня непонятно. Ну ладно, будем считать, что это мой косяк и неудачно построенная фраза. Но после этой фразы идёт ещё с десяток моих комментариев (например, непосредственно следущий за тем, что вы процетировали), где я поясняю свою мысль, развеивая идею, что я каким-то образом почему-то против тестов. Но нет, вы, почему-то, предпочли пропустить всё это, и на основе одной неправильно понятой вами фразы сделать выводы о моей квалификации. Ура, товарищи, отличный вывод!bigfatbrowncat
22.08.2015 10:56-1В языках «таких как Java» не требуется добавлять временный метод main, так как достаточно проставить точку останова в нужное место и после этого ввести в Watch нужное вам выражение.
Я ничего не пропускал, я ответил на вот это заявление:
85% времени при разработке на Python я провожу в режиме «написать функцию -> проверить в REPL». Т.е. подавляющее большинство операций, которые я выполняю, напрямую связаны с переключением между текстовым редактором и REPL.
Я никаких выводов не делал. Всего лишь указал вам на то, что считаю неверным и предупредил, что вас могут понять превратно.ffriend
22.08.2015 16:23+1В языках «таких как Java» не требуется добавлять временный метод main, так как достаточно проставить точку останова в нужное место и после этого ввести в Watch нужное вам выражение.
А теперь давайте поиском по странице найдём мой комментарий со словом «watch», в котором я подробно рассказываю, почему дебаггер + watch даже рядом не стоят с REPL.
Я никаких выводов не делал. Всего лишь указал вам на то, что считаю неверным и предупредил, что вас могут понять превратно.
Интересный у вас способ отреагировать на это заявление, если процитировали вы совершенно другое. Ну ладно, пусть будет по-вашему. Может быть у вас есть какие-то аргументы, почему вы считаете, что я на своём языке программирования делаю свои же задачи неправильно? Расскажите мне, пожалуйста, как мне правильно программировать на Python и самое главное почему?bigfatbrowncat
23.08.2015 09:51-1Расскажите мне, пожалуйста, как мне правильно программировать на Python и самое главное почему?
Надеюсь, мое мнение вас не оскорбит. Но мне python не нравится совсем. И я вообще предпочитаю на нем не программировать. Это — уже совсем другой спор…
Вы радуетесь в своем любимом языке вещам, которые меня в нем раздражают. А я, например, очень радуюсь, что в Java есть checked exceptions, которые вызывают недоумение у python-разработчиков (и не только у них). Это — тоже своего рода религия.
Мой лучший друг — питонщик. Мы никогда не сможем в этом друг друга понять. Мировая наша с ним состоит в том, что питон удобен для маленьких программ, а Java — для больших. Это — единственный консенсус в области идеологии, которого мы смогли достигнуть.
Боюсь, что это тесты очень часто используются только из-за того, что в языке нет REPL.
Я вам процитировал эту фразу, потому что предыдущую вам процитировали выше. А так как я комментарии читал сверху вниз и отвечал последовательно, то, что вы писали ниже, я прочел позже.ffriend
23.08.2015 14:37+1Надеюсь, мое мнение вас не оскорбит. Но мне python не нравится совсем. И я вообще предпочитаю на нем не программировать. Это — уже совсем другой спор…
Вот в следущий раз лучше сразу начинайте комментарий со слов «по-моему мнению», это снимет много вопросов.
Мировая наша с ним состоит в том, что питон удобен для маленьких программ, а Java — для больших.
Охх, как же уже надоели эти мифы...
А так как я комментарии читал сверху вниз и отвечал последовательно, то, что вы писали ниже, я прочел позже.
Т.е. вы сначала прочитали первое предложение, потом ответили, а потом дочитали комментарий? Окааай.webkumo
23.08.2015 15:22-2А наличие крупных проектов на языке что-то говорит об удобстве написания оных на нём? Код ядра линукс тоже долгое время был на чистых сях, потом переехал на плюсы, если мне память не изменяет.
ffriend
23.08.2015 16:19Код ядра линукс тоже долгое время был на чистых сях, потом переехал на плюсы, если мне память не изменяет.
Ага, аж на 0.6%.roman_kashitsyn
23.08.2015 20:55+1Ага, аж на 0.6%.
Хм, гитхаб почему-то считает все сишные хедеры написанными на языке с++…
roman_kashitsyn
23.08.2015 20:55+1Код ядра линукс тоже долгое время был на чистых сях, потом переехал на плюсы, если мне память не изменяет.
Память вам изменяет. Линус ни за что не пустит плюсы в ядро.
Возможно, вы имели в виду GCC.
bigfatbrowncat
23.08.2015 23:27-3YouTube — жуткая дрянь в плане надежности. Не думаю, что дело в том, на чем он написан. Но факт остается фактом. То стриминг глючит, то еще что-то…
Но комментатор ниже прав: наличие крупных проектов само по себе не доказывает, что язык для них пригоден. Вот, Facebook и Wikipedia вообще, прости господи, на PHP написаны. А работают. Но сколько же туда усилий и пота кровавого вложено…ffriend
23.08.2015 23:51+1Естественно, все ж дураки, один вы знаете, как крупные проекты нужно писать.
Alexeyslav
24.08.2015 10:55Зато мы теперь знаем как их НЕ НУЖНО писать.
Крупные проекты это такая штука… никогда нельзя сказать насколько сложными они окажутся через пару лет используя конкретные технологии. А при неудачном выборе, попытка переписать на более подходящих технологиях аналогична разработке с нуля со всеми вытекающими.ffriend
24.08.2015 12:22Проблема роста проекта успешно решается через модульность уже много лет. Причём модульность в любом виде, так что даже проекты на C, в котором на уровне языка такого понятия нет, прекрасно растут просто за счёт правильной организации кода и инклюдов. Единственная проблема масштабируемости, которая зависит от языка и технологии, это проблема роста производительности. Но к организации кода она не имеет никакого отношения.
bigfatbrowncat
24.08.2015 11:00Причем тут я? Я участвовал в крупных проектах, которые писались хорошо. И участвовал в тех, которые писались плохо. И в том, и в другом случае я старался сделать лучше. Однажды мое нежелание делать дрянной код двигаясь на поводу у людей, не желающих думать в процессе разработки привело к тому, что я просто ушел из проекта. Потому что на мои попытки улучшить архитектуру архитекторы отвечали мне: «идея твоя хороша и верна, но мы ее не будем внедрять, так как в команде есть люди, которые ее не поймут». При этом и они, и я хорошо понимали, о ком именно идет речь.
О чем это я? О том, что 1000 обезьян может быть и не напишут «Войну и Мир» за год, стуча по машинкам, но зато они обойдутся фирме намного дешевле, чем 2-3 писателя. А разницы в готовом продукте всё равно никто не заметит, пока этот продукт — лидер и почти монополист. «Nothing personal, just business»ffriend
24.08.2015 12:26Не понял, какое отношение ваш комментарий имеет к вопросу удобства написания крупных проектов на разных языках?
bigfatbrowncat
24.08.2015 16:54-1Вы меня обвинили в самоуверенности на основании моих чисто пользовательских наблюдений за YouTube. Я решил ответить на это заявление.
Встречный вопрос: какое отношение имеет к качеству YouTube-а мое умение или неумение делать крупные проекты правильно? Я лишь указал, что приводить его в качестве примера удачи — неверно.ffriend
24.08.2015 17:57Вы меня обвинили в самоуверенности на основании моих чисто пользовательских наблюдений за YouTube.
Я вам про YouTube вообще ничего не говорил, это вы почему-то выбрали из списка крупных проектов на Python тот, с которым у вас не сложилось, и на этом примере стали рассказывать про то, что одни языки предназначены для крупных проектов, а другие нет.
А ответил я вам на вот это:
Но комментатор ниже прав: наличие крупных проектов само по себе не доказывает, что язык для них пригоден.
Flammar
21.08.2015 11:01+1Думаю, скорее, вместо «постоянной пересборки проекта в фоновом режиме» при написании программ на Java в IDE типа Eclipse. То же самое, только руками. И в эти «85% времени разработки» входит не только проверка в REPL, но и собственно написание функции.
ffriend
21.08.2015 21:35Думаю, скорее, вместо «постоянной пересборки проекта в фоновом режиме» при написании программ на 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-тестами :)bigfatbrowncat
23.08.2015 10:46-1Из ваших слов создается впечатление, что главная проблема IDE для питона состоит в том, что ее нет… Вернее, в том, что она ужасно недоработана.
Позвольте, я вам «притчу» расскажу.
Есть такая компания — IBM. Гигантская, к слову, компания — что только ни производит, чем только ни занимается. И вот занялась она Джавой. Всерьез занялась, поскольку язык этот ей показался очень перспективным. Шел конец 90-х, Java-апплеты еще встречались на сайтах, а Java Enterprise еще только начинался и едва конкурировал с Perl-ом в папочке cgi-bin.
А IBM со свойственным им размахом начали чудовищного размера проект, писать который предстояло долго и упорно. Ну то есть сейчас он уже чудовищного размера. А тогда, ясное дело, только начинался.
И так как вложено в проект было очень много, им необходима была реально крутая отдача от разработчиков. И какой-то мудрый человек (увы, не знаю, как его звали) решил в 2001 году вложиться в создание крутой профессиональной Java IDE. Учитывая их бюджет, расходы на написание IDE были сущей мелочью — и они ее написали. Тяжелую и профессиональную, с высоким порогом вхождения и всеми необходимыми фичами. Написали не «за бабки», а «для себя» — и много лет вылизывали и тестировали этот JDT, будь он неладен. Сейчас он сияет и переливается. Уже года два не видел, чтобы eclipse в чистом java-проекте падал, если не прицеплять всякие левые JBoss-поделки. Завидная стабильность по сегодняшним временам!
И именно благодаря этому у джавистов сегодня есть эта замечательная штука — Eclipse. И, как мне кажется, это является главным критерием «зрелости» языка — если огромная компания готова создать мощную IDE для этого языка даже не на коммерческой основе, а так, как поделку, как побочный продукт своей технологии.
Надеюсь, что кто-нибудь и за python возьмется. И будет следующее (или даже это) поколение питонщиков с удивлением тут писать: как вообще можно код править в vim? Есть же «Pyclipse»!ffriend
23.08.2015 17:55+1А хотите, я вам расскажу альтернативную притчу? C 91 по 95 год человек по имени Джейсм Гослинг работал над языком Oak в компании Sun Microsystems. Sun Microsystems на тот момент, вообще говоря, была не столько софтварной, сколько хардварной компанией, производящей большое разнообразие серверов, десктопных и микрокомпьютеров. Естественным желанием компании было найти общий знаменатель для всех своих систем. Отсюда и появился Java bytecode, а также знаменитый лозунг «write once, run anywhere».
В начале 2000х случился бум доткомов, тотальное распространение интернета и клиент-серверного ПО. Если есть потребность в программах, есть и потребность в разработчиках, способных их создавать. Проблема в том, что в тот момент достаточно квалифицированных разработчиков, способных писать на менстримовом C++ серверное ПО, которое бы не «текло» и не приводило к segfault-ам, было гораздо меньше, чем требовалось. Процесс обучения новых рекрутов был длительным и болезненным, поэтому нужно было снижать планку.
И вот тут Java выстрелила. В ней не нужно было следить за выделением и освобождением памяти, не нужно было учить 100500 замысловатых конструкций и концепций языка и даже исключения везде указывались явно, так что забыть их проверить было просто невозможно. Просто идеальный язык для толпы низкоквалифицированных недоспециалистов.
Но одной только смены языка недостаточно, чтобы успешно (с точки зрения дальнейшей продажи) писать большие проекты. Всё-таки нужны были тим лиды, простые правила, показывающие, как «правильно», и постоянный рефакторинг. Вручную перерефакторить говнокод, написанный толпой обезъянок, — та ещё работёнка. Поэтому нужны были средства для упрощения поиска нужных классов (из структуры директорий то непонятно, где что лежит), массового переименования (сразу то подумать как назвать переменную нельзя), вынесения методов в общий абстрактный класс (ведь простые правила, которые показал тимлид, в данном случае оказались слишком упрощёнными).
А как автоматизировать все эти задачи? Правильно, написать IDE, которая не заставит недоспециалистов писать хороший код, но позволит потом проще разгребать получившуюся кашу. И именно поэтому, как уже неоднократно замечали тут в комментариях, Java — это практически единственный язык, писать на котором без IDE просто невозможно.
Вся эта история, конечно, ложь и профанация — я за спиной у Гослинга и IBM не стоял, и как всё было на самом деле знать не могу. Но скажите, чем ваша история лучше?webkumo
23.08.2015 18:38+1Кхм… т.е. на плюсах пишут только труъ-профи? ;)
«Поэтому нужны были средства для упрощения поиска нужных классов (из структуры директорий то непонятно, где что лежит)» — невозможно создать абсолютно продуманную структуру директорий + неймспейсы бывают очень полезны (но накладывают ограничение на модель хранения — ту самую структуру директорий). А если подключить ещё пару фреймворков и вспомнить огромное JDK — то даже на простом проекте без поиска приходится тяжеловато (все классы не запомнишь).
«массового переименования (сразу то подумать как назвать переменную нельзя)» — можно, но в процессе написания кода, бывает, приходит понимание более точного названия — вручную переименовывать?
«вынесения методов в общий абстрактный класс (ведь простые правила, которые показал тимлид, в данном случае оказались слишком упрощёнными)» — опять же в процессе разработки класс разрастается + появляются классы с похожим функционалом — вынести общее в общий абстрактный — вполне себе вариант. Или вы пишите только по заранее утверждённому ТЗ и в дальнейшем никогда не меняете код?
И да, вы ещё забыли кучу различных рефакторингов «вынести в метод», «вынести в переменную», «вынести в константу», «использовать интерфейс, где возможно» и прочие-прочие… Как вы смогли упустить такой пласт для отзывов об «обезъянках»?ffriend
23.08.2015 19:35+1Кхм… т.е. на плюсах пишут только труъ-профи? ;)
Это значит, что на подготовку более или менее самостоятельного C++ разработчика уходит чертовски много времени.
А если подключить ещё пару фреймворков и вспомнить огромное JDK — то даже на простом проекте без поиска приходится тяжеловато (все классы не запомнишь).
Apache Spark — прекрасный пример, где структура директорий практически однозначно определяет местоположение какого-то куска кода. По сути, если пропустить общий для всех пакетов префикс «org.apache.spark», то получается практически двухуровневая иерархия — имя подпакета (например, «rdd», «storage», «scheduler») и дальше список файлов-классов.
можно, но в процессе написания кода, бывает, приходит понимание более точного названия — вручную переименовывать?
Внешний API модуля меняется редко, так что на практике даже ручное переименование не создаёт особых проблем. Т.е. фича полезная, но не критичная.
опять же в процессе разработки класс разрастается + появляются классы с похожим функционалом — вынести общее в общий абстрактный — вполне себе вариант.
Ctrl+X Ctrl+V раз в месяц — не проблема, проблема именно когда рефакторинг становится ежедневным и/или длительным процессом.
И да, вы ещё забыли кучу различных рефакторингов
Я ничего не забыл, но ведь и вы помните, что всё это спекуляция, и к реальности может не иметь никакого отношения?webkumo
23.08.2015 20:19«Внешний API модуля меняется редко, так что на практике даже ручное переименование не создаёт особых проблем. Т.е. фича полезная, но не критичная. „
Когда случается потребность (пусть и редкая) — становится очень даже критичной. Ну и для работы с внутренними переменными тоже бывает полезно
“Ctrl+X Ctrl+V раз в месяц — не проблема, проблема именно когда рефакторинг становится ежедневным и/или длительным процессом.»
Не проблема… но геморрой… Это как вместо cvs использовать бекапы — можно, но неудобно. Инструменты рефакторинга это делать аккуратнее, быстрее и с лучшим охватом мест использования (не приходится их искать).
«Я ничего не забыл, но ведь и вы помните, что всё это спекуляция, и к реальности может не иметь никакого отношения?»
Понимаю, но слишком уж максималитичо было сказано.ffriend
23.08.2015 20:40Когда случается потребность (пусть и редкая) — становится очень даже критичной. Ну и для работы с внутренними переменными тоже бывает полезно
Внутренние переменные прекрасно заменяются через string replace, так что это вообще не проблема. Для внешних вполне работает grep и sed. Но если это может делать IDE, то это несомненный плюс, тут не поспоришь. Однако я честно не думаю, что IDE для Java получили такое развитие только из-за необходимости время от времени переименовывать переменные.
Инструменты рефакторинга это делать аккуратнее, быстрее и с лучшим охватом мест использования (не приходится их искать).
Да ладно, что именно во внешних зависимостях поменяется, если вы часть методов вынесите из данного класса в его абстрактного предка?
Понимаю, но слишком уж максималитичо было сказано.
Я это к тому, что никогда нельзя делать однозначные заявления о том, почему и зачем что-то произошло. И никогда не стоит решать за других людей, как им удобней работать и какие инструменты для них важнее.
bigfatbrowncat
24.08.2015 17:15-1Ваша история ничем не лучше моей. Но в ней-таки слишком много неоправданной злости. Даже хамства, я бы сказал.
Я сознательно перешел на Java с C++, уже имея весьма солидный опыт написания программ на нем. Потому что я, по вашему определению, «самоосознанная обезьянка».
1. Я считаю, что язык C++ образца 98 года ужасен, потому что не позволяет отделаться от кучи мелких ошибок. Даже опечатки в нем часто приводят к багам, над которыми приходится просидеть неделю. Попробуйте на досуге поиграть в «русскую рулетку» — найдите и удалите в большом проекте случайный символ "&". Язык, в котором подобной дряни не наблюдается, несомненно лучше. И для разработчиков, и для пользователей.
2. Я считаю, что регулярное переосмысление архитектуры проекта и последующий рефакторинг «говнокода» — неизбежная санитарная процедура. И если вы думаете, что лично вы не производите этот «говнокод» в промышленных масштабах, то смею вас заверить. Его производят абсолютно все, вне зависимости от языка и квалификации. С первого раза ни одна система не строится.
И, наконец:
3. Я убежден, что разработка ПО требует мышления в рамках некоторой выбранной парадигмы. И чем строже вы ограничиваете себя этой парадигмой (будь то ООП, ФП или даже АОП), тем качественнее ваш выхлоп. И, да, я предпочитаю, чтобы меня ограничивал компилятор, а системы статического анализа моего кода были встроены в тот текстовый редактор, в котором я этот код набираю и «били меня по башке» всякий раз, когда я пишу дрянь. Спортсмены вполсилы не играют даже с младшей сестренкой во дворе. Это расхолаживает.
Я не знаю, чем на самом деле руководствовались IBM. Но если вашу историю придумали вы, то я вынужден считать, что она больше характеризует вас самого, нежели кого-то другого.
Кстати, прекрасный пассаж:
В ней не нужно было следить за выделением и освобождением памяти, не нужно было учить 100500 замысловатых конструкций и концепций языка и даже исключения везде указывались явно, так что забыть их проверить было просто невозможно.
Во-первых, потрудитесь почитать хоть что-то вот от этого господина, например. Вы поймете хотя бы приблизительно, какого уровня задачи решают «обезьянки» в своей повседневной работе. А если хотите знать, что им приходится учить, то, например, вот.
А во-вторых, посмотрите, как часто в вашем любимом проекте вылетают исключения, которые кто-то по ошибке забыл поймать. И подумайте, наконец, — друг вам тот, кто ваши ошибки помогает вытащить наружу, или враг.
Java — это практически единственный язык, писать на котором без IDE просто невозможно.
Неверное утверждение. И никто тут этого не писал. Верное утверждение такое:
Java — почти единственный язык, инфраструктура которого развита до такого высокого уровня, что ни один адекватный человек не станет работать отшельником хрен-пойми-в-чем, вместо использования нормального, специально предназначенного для Java инструмента.
Попробуйте — поймете.ffriend
24.08.2015 18:32+2Потому что я, по вашему определению, «самоосознанная обезьянка».
Никаких определений я не давал.
Я считаю, что язык C++ образца 98 года ужасен
Да. И это никак не противоречит тому, что я написал.
Я считаю, что регулярное переосмысление архитектуры проекта и последующий рефакторинг «говнокода» — неизбежная санитарная процедура.
Рефакторинг — да, говнокода — нет. Достаточно освоить всего пару базовых принципов, чтобы свести 85% случаев рефакторинга к изменению внутри одного модуля.
Я убежден [...]
Вы правильно начали фразу, но не забывайте, что не все разделяют ваши убеждения.
Во-первых, потрудитесь почитать хоть что-то вот от этого господина, например. Вы поймете хотя бы приблизительно, какого уровня задачи решают «обезьянки» в своей повседневной работе.
Читал. И какого же уровня эти задачи?
А если хотите знать, что им приходится учить, то, например, вот.
Да, именно про них я и говорил. Это что-то меняет в моей фразе?
А во-вторых, посмотрите, как часто в вашем любимом проекте вылетают исключения, которые кто-то по ошибке забыл поймать.
Те, которое кто-то по ошибке забыл поймать — нечасто. Те, которые должны специально сломать стек и сигнализировать про исключительную ситуацию — чаще, и это хорошо.
Попробуйте — поймете.
Попробовать что? Я 5 лет писал на Java как на основном языке программирования. Работал и с IDEA, и с Eclipse, и с Netbeans и ещё с парой мнее известных IDE. Видел и энтерпрайз проекты, над которыми работали сотни разработчиков, и опен сорс решения, крутящиеся на сотне серверов. И видел как прекрасно растут системы, написанные на Java, Scala, Python, Erlang и десятке других языков, набираемых в IDEA, Vim, Emacs и просто в блокноте.bigfatbrowncat
25.08.2015 01:22Ваши рассуждения в моем понимании совершенно не вяжутся с вашей квалификацией. После 5 лет в энтерпрайзе люди обычно не утверждают, что регулярный рефакторинг бывает нужен, чтобы «подчищать за обезьянками», а для создания качественного кода «достаточно понимать всего пару принципов». Может быть, я просто не дорос до вашего уровня. Допускаю. Или я вообще не понял, что вы имели в виду и нас унесло от изначальной темы.
В любом случае, этот спор совершенно бесплоден. И продолжать его я смысла не вижу, о чем бы он ни шел. Простите за потраченное время.ffriend
25.08.2015 01:32регулярный рефакторинг бывает нужен, чтобы «подчищать за обезьянками», а для создания качественного кода «достаточно понимать всего пару принципов»
Эх, ну вот опять вы читаете больше, чем написано… Ну да ладно, спор действительно пора заканчивать. Приятного вечера или что там сейчас в вашей временной зоне.
Flammar
25.08.2015 12:19дебаггер не может сделать step back
Кстати, вот за это я их и не люблю. Особенно «весел» дебаггинг при отладке серверных систем, которые стартуют по 10 минут — приходится кучу раз делать запрос и кучу раз перестартовывать (по 10 минут каждый) чтобы выяснить причину. Был бы step back — цены бы такому дебаггеру не было.
BelBES
25.08.2015 15:46Хм, банальный GDB, например, умеет делать reverse execution, но для этого его нужно запускать с логированием состояния.
Flammar
25.08.2015 12:20Вообще такая «REPL-ориентированная» разработка напоминает разработку на форте из книжек по форту.
vlivyur
21.08.2015 13:22А можно пример IDE где удобно XML редактировать?
bigfatbrowncat
23.08.2015 10:57А что вам «удобно»? :) Вот, попробуйте это: marketplace.eclipse.org/content/rinzo-xml-editor
bigfatbrowncat
23.08.2015 15:53Новое название для Word-а IDE для написания служебных записок :)
А если серьезно, то вы абсолютно правы.
PerlPower
20.08.2015 23:10+19Если какой-то спор идет десятилетиями, однозначного решения его не видно, и никто из противоборствующих сторон не раскаивается в своем выборе, то мы имеем дело с обыкновенной вкусовщиной. Но до чего же приятно доказать себе и другим, что именно твой способ делать что-то — самый правильный.
js605451
21.08.2015 01:13Стиль работы может быть очень разным как для разных ЯП, так и в пределах одного ЯП, но для разных задач.
- Для JavaScript в принципе не может существовать полноценной IDE, потому что JS — очень-очень динамический. Ни контекстные подскази толком не сделаешь (разве что вывалить все названия какие встречаются в коде), ни рефакторинги автоматизируешь, потому что без выполнения программы практически невозможно точно узнать что делает какой-то кусок кода. А с такими ограничениями от IDE толком ничего и не остаётся — подсветка, кнопки для запуска разных задач и получаем в итоге тот же Sublime.
- У всяких Java и C# таких ограничений почти нет (в C# такие есть динамические типы, но очень-очень не повсеместно). Поэтому и по коду прыгать удобно — всегда понятно откуда берётся какое-то имя, и рефакторинги замечательно работают, т.к. разночтений в принципе быть не может. В этом случае IDE даёт намного больше, чем в первом.
PerlPower
21.08.2015 01:48Продолжайте наблюдения.
js605451
21.08.2015 02:29Что-то не так с моим комментарием?
PerlPower
21.08.2015 03:06Я не понял какая связь между моим комментарием и вашим, поэтому подумал, что вы поделились своими наблюдениями, или, возможно, ошиблись веткой.
js605451
21.08.2015 03:30Нет, это моё мнение по поводу вашего «мы имеем дело с обыкновенной вкусовщиной». Вкусовщина безусловно имеет место, но она не на первом месте. На первом месте — специфика ЯП и техническая возможность сделать какие-то плюшки для него. Рассмотрены 2 условных семейства ЯП, показано, что «вкусовщина» более применима к JS и подобным (IDE почти равно редактору с плагинами), а для C#/Java редактором будет пользоваться только извращенец (IDE даёт очень многое).
Резюмируя: вкусовщина не на первом месте.PerlPower
21.08.2015 03:40+1А как вы объясните эту толпу извращенцев, которые вместо использования eclipse тащат его в vim и emacs? github.com/ervandew/eclim
Тут либо вкусы на первом месте, либо в редакторе удобней, чем в IDE.js605451
21.08.2015 04:00+3Хакерский романтизм и шило в заднице — не более.
PerlPower
21.08.2015 04:18+2Весьма универсальный аргумент.
js605451
21.08.2015 04:27+3Он здесь уместен. Есть программисты, которые просто работают за зарплату. Есть программисты, которым нравится работать круто — тренироваться делать фичи быстрее и качественнее. А есть программисты, которые любят возиться с инструментами надеясь, что как только оно заработает, качество их работы вырастет на порядок и вот тогда-то уж они запрограммируют всё-всё-всё.
Та толпа извращенцев — из 3-ей категории.PerlPower
21.08.2015 05:06+1А мне кажется, что программист, который потянет проект уровня eclim должен быть достаточно умен для того, чтобы осознать, что его возня с редактором не дает должной отдачи.
bigfatbrowncat
22.08.2015 03:13Или у него просто идея-фикс: всё всегда редактировать только в Vim. Просто, Vim — это такая религия.
poxu
21.08.2015 10:25+3vim и emacs уникальные редакторы. Подход к редактированию текста там радикально отличается от подхода к редактированию текста в блокноте. Большинство IDE это в общем блокнот обвешанный фичами. Редактировать текст там откровенно неудобно.
Спор между IDE и vim с emacs это не спор между текстовыми редакторами и IDE. Это спор между разными подходами к редактированию текста. Если бы в IDE был нормальный текстовый редактор — адепты vim и emacs перешли бы на эту IDE не задумываясь.
Поэтому и тащат eclipse в vim и emacs. Чтобы было нормальное редактирование текста плюс возможности IDE.
bigfatbrowncat
23.08.2015 10:05-1Для JavaScript в принципе не может существовать полноценной IDE
С этой задачей вполне успешно справляется любой современный браузер. Там есть всё — и debug, и watch, и автодополнение, и даже измерение производительности.
без выполнения программы практически невозможно точно узнать что делает какой-то кусок кода
Это лишь означает, что язык — дрянь. Но всё, что можно было выжать (я выше перечислил), выжали. Это — уже больше, чем позволяла любая самая крутая IDE для C++ 15 лет назад.
в C# такие есть динамические типы
Это не мешает определить типы данных на этапе компиляции. А значит рефакторинг будет работать.
ffriend
20.08.2015 23:12+6Мне кажется, у вас либо мало опыта, либо просто какой-то bad luck с тем, что вы называете редактрами. Например:
Попробуйте, скажем, включить нумерацию строк в том же emacs!
Мне хватило 15 секунд, чтобы нагуглить, что нумерация строк включается командой `M-x linum-mode`. Хотя лично мне всегда хватало номера строки и колонки в статусной строке внизу активного окна. Подсказки и автодополнения зависят от мода — практически во всех специализированных модах, которые я использую — они есть. Поиск нужного файла тоже много где реализован, плюс, насколько я помню, доступен в виде отдельного мода (могу поискать, если хотите). Key bindings изменяются элементарно на что вам нравится через `(gloabl-set-key ...)` и `(local-set-key ...)`. Дебаггерами практически не пользуюсь, но гугль говорит, что их тоже не хватает.
Не могу говорить за все редакторы, но Emacs при желании — это не только IDE, но и практически полноценная операционная система, просто менее специализированная под конкретные языки, как Visual Studio или Eclipse.
n0dwis
20.08.2015 23:54-4Вот именно — гуглится. Т.е. даже такую элементарную вещь включить без помощи гугла — никак. А что говорить о более сложных вещах?
Поиск файла — да. В том же projectile работает. Только я с ним 2 дня медитировал, пока разобрался со способами индексации и удалось получить приемлемую скорость работы этой функции.
Тем не менее, мне нравится с этим ковыряться — даже про lisp кое-что почитывать начал. Но не всегда есть время и желание гуглить 2 дня для добавления нужного функционала. Я поэтому пока с отладчиком в emacs и не связываюсь.
Emacs при желании — это не только IDE, но и практически полноценная операционная система
которой не хватает хорошего текстового редактора :)ffriend
21.08.2015 00:23+5Вот именно — гуглится. Т.е. даже такую элементарную вещь включить без помощи гугла — никак. А что говорить о более сложных вещах?
Эмм… А как это должно было быть? Если гуглить — это, по-вашему, долго и сложно, то можно просто начать набирать `M-x line-...`, и Emacs вам сразу выдаст 2 режима для номера строк. Но всё-таки с гуглом удобней, как для Emacs, так и для IDE.
Поиск файла — да. В том же projectile работает. Только я с ним 2 дня медитировал, пока разобрался со способами индексации и удалось получить приемлемую скорость работы этой функции.
Опять же, за 30 секунд нагуглил родную функцию `locate`, которая находит файл внутри какой-то директории. Загуглил — потому что для того же Python у меня автоматически включается умная подстановка пути по `C-x f`.
которой не хватает хорошего текстового редактора :)
Старая и несправедливая шутка :) Emacs — это непривычный текстовый редактор, да, но плохим его назвать точно нельзя.n0dwis
21.08.2015 00:53-1Если гуглить — это, по-вашему, долго и сложно, то можно просто начать набирать `M-x line-...`,
Это не «сложно и долго». Это — излишне сложно и долго. Зачем мне вообще знать эту команду? Почему не мышкой? Нет, я понимаю, конечно, почему в emacs-е это так. Но это же является недостатком для промышленного использования — слишком сложно.
Emacs — это непривычный текстовый редактор, да, но плохим его назвать точно нельзя.
От org-mode я вообще в восторге!ffriend
21.08.2015 01:20+1Это не «сложно и долго». Это — излишне сложно и долго. Зачем мне вообще знать эту команду? Почему не мышкой? Нет, я понимаю, конечно, почему в emacs-е это так. Но это же является недостатком для промышленного использования — слишком сложно.
15 секунд и гугль раз в жизни — это слишком сложно? Ммм…
GooRoo
21.08.2015 18:23При таком раскладе гуглопоиск должен быть встроен в emacs из коробки.
salas
21.08.2015 23:48Не из коробки, но идея интересная, и кому-то она в голову уже пришла. Особенно интересной кажется вариация с шорткатом для поиска по сообщениям об ошибках.
Delphinum
21.08.2015 02:25+4Это не «сложно и долго». Это — излишне сложно и долго
А программировать вы тоже начали методом тыка, или все же прочли пару мануальчиков?GooRoo
21.08.2015 18:24С каких это пор программирование и использование программ — равносильные понятия?
Delphinum
21.08.2015 23:46С тех пор, с каких для эффективной работы нужно уметь пользоваться инструментами. Как считаете, можно быть хорошим столяром, не умея пользоваться молотком?
GooRoo
22.08.2015 02:04-1Не помню, чтобы мне приходилось гуглить, чтобы научиться пользоваться молотком. Или изучать устройство молотка. Или подготавливать специальным образом руки к работе с молотком. Выше ключевое слово — «излишне».
salas
22.08.2015 04:40Вы уверены, что учились пользоваться молотком «без гугла», т.е. абсолютно самостоятельно, извлекая информацию об этом деле только из молотка, досок и гвоздей? Ни разу даже не видели, как их забивает кто-нибудь более опытный, прежде чем первый раз попробовать самому?
GooRoo
22.08.2015 12:00Видел, конечно. И этой информации хватило.
salas
22.08.2015 16:38ЧТД. А если смотреть, как кто-нибудь работает с Emacs, Visual Studio или Photoshop — те функции, которыми они активно пользовались, гуглить, вероятно, тоже не понадобится. Но, да, смотреть придётся более внимательно, к молотку наше подсознание эволюция лучше подготовила, чем к мэйнстримным устройствам управления компьютером.
Delphinum
22.08.2015 11:21-1Возможно вы не поняли, но «молоток» в моем примере, это лишь абстракция, обозначающая инструмент мастера. Замените «молоток» в вашей голове на фрезерный станок TF 200 SE.
salas
21.08.2015 03:01+2Почему не мышкой?
Мышкой куда? Попробовал включить в PyCharm те же самые номера строк, без гугла не осилил. А M-x line-<TAB> — вероятно, догадался бы. Впрочем, существенным недостатком PyCharm это не считаю, потому как гугл — это несложно и недолго.Miklos
21.08.2015 03:08Два раза shift или ctrl+shift+a и там можно искать интересующее. Например, show numbers.
salas
21.08.2015 03:43О, спасибо. Вот что в меню Navigate перечислены не все команды поиска, а к невзрачной серой лупе на тулбаре стоит присмотреться отдельно, я и не догадался. И инструкцию не прочёл — кажется, в этом треде не зазорно в таком признаться.
Но, чёрт возьми, это же прямо супермаркет какой-то: самый ходовой товар — не на полке с аналогичными, а на другом конце зала.
Dolios
21.08.2015 15:11Но, чёрт возьми, это же прямо супермаркет какой-то: самый ходовой товар — не на полке с аналогичными, а на другом конце зала.
Не соглашусь. В 9х% случаев знаешь где искать (в именах файлов, в текущем файле, в именах опций, ect) и вызываешь соответствующий шорткат. Дабл шифт лично я использую крайне редко. Когда действительно не понятно, «куды бечь».
Bringoff
21.08.2015 08:32+1В Android Studio ПКМ по месту, где должны быть номера, Show line numbers. Зачем там нужен был гугл, непонятно.
PerlPower
21.08.2015 00:36+3Просто воспринимайте емакс как конструктор текстового редактора. И если вам некогда возиться с конструктором, то логично использовать IDE. Но если вы emacs до сих пор не выкинули, то вы подружитесь, пусть и через пару лет.
BelBES
21.08.2015 00:39Просто воспринимайте емакс как конструктор текстового редактора. И если вам некогда возиться с конструктором, то логично использовать IDE.
Я наверно совсем не труЪ emacs-пользователь, но в целом я поднастроил себе редактор всего за месяц… с тех пор фундаментальных изменений больше не вносил и мне моего конфига вполне хватает) Правда пришлось смириться с тем, что некоторые иногда удобные фичи в emacs настроить нельзя.PerlPower
21.08.2015 01:34Вы счастливый человек, а я все думаю спустя 10 лет пользования emacs что еще можно утянуть себе из melpa.
BelBES
21.08.2015 10:33У меня единственное чего не хватает в конфиге, так это автокомплита с семантическим дополнением и переходы к определению/реализации, но эти фичи впринципе качественно не настраиваются в emacs, т.ч. я смирился)
bigfatbrowncat
22.08.2015 03:17я поднастроил себе редактор всего за месяц
Всего… за месяц…
Вы знаете, я, конечно, не скажу за вас — не знаю, что вы там делаете в нем и какие тонкости решаете, но когда я настраивал себе eclipse, чтобы он нормально код форматировал (не переносил 81-й символ на новую строку и т п...) и немного хоткеи менял, а потом конфигурил в нем проектный файл для C++-проекта, то на всё ушло пара часов и мне это показалось очень долго.BelBES
22.08.2015 12:01+11) Месяц настройки — это н значит, что я месяц настраивал редактор прежде, чем начал им пользоваться. Это значит, что я все свои хотелки добавлял по мере надобности в течении примерно месяца)
2) Вот конкретно eclipse я несколько раз пробовал использовать, и всегда он мне казался каким-то неудобным и нелогичным. До emacs я исопльзовал QtCreator, который меня устраивал всем, кроме того, что в нем нельзя было работать без использования мыши. Собственно из-за этого я и перешел с него на emacs и даже несмотря на отсутствие некоторых фич, которые были в креэйторе, работа в emacs все равно оказалась удобней.bigfatbrowncat
23.08.2015 10:11-1Eclipse мне тоже поначалу показался нелогичным. Просто, у него довольно высокий «порог вхождения». Он на первом же уровне формирует у пользователя нетривиальные понятия типа workspace, debug configuration и прочее. Но зато как только вы поймете смысл всего этого, вы увидите четкую структурированность и железную логичность архитектуры. В Idea, на первый взгляд, более логичную, многие фичи прикручены в весьма странных местах в угоду новичкам, которые не желают привыкнуть к идеологии системы. Так как я всё всегда изучаю «от устройства к внешнему виду», мне eclipse ближе. Но на emacs я, всё же, не согласен.
BelBES
23.08.2015 10:42+2В Eclipse нет ничего нетривиального, там есть нелогичное. И разница в том, что к eclipse нужно «привыкать к идеалогии системы», а в emacs все настраивается по своему вкусу.
bigfatbrowncat
24.08.2015 10:53-1Что вам там показалось нелогичным? Мне правда интересно. Просто хотя бы какой-то конкретный пример.
Мне, на самом деле, Emacs вообще не кажется конкурентом eclipse-а в плане работы с Java кодом. Слишком несопоставимые возможности.
И я считаю, что если на данном этапе какая-то IDE для своего языка сопоставима по возможностям с Vim и Emacs, то она попросту недоделана.BelBES
24.08.2015 10:59+1Я последний раз Eclipse открывал года 3-4 назад, т.ч. конкретных примеров сейчас назвать не смогу. Ну и да. я её не для Java, а для C++ использовал.
bigfatbrowncat
24.08.2015 11:05Для работы с C++ Eclipse необходимо настраивать. Увы, CDT при всей своей универсальности далек от совершенства. Но при этом я не знаю ни одной другой среды, настолько всеядной в плане парадигм и компиляторов. Хотите mingw? Окей. Хотите MS C++? Без проблем. Хотите makefile? Вам сгенерировать? Или свой подложите? Хотите кросс-платформенное приложение одновременно на C, Java и Фортране? Да пожалуйста! Только 3 плагина поставьте в среду, да настроечки пропишите. И будет вам во всех трех языках intellisense.
Вы знаете, что меня раздражает в Eclipse на данный момент? То, что Ctrl+Click по декларации native-функции в Java не вызывает имплементацию этой функции в JNI-слое на C. И, да, я считаю, что это из разряда «мелких бриллиантов»BelBES
24.08.2015 11:27+1Ну практически весь функционал Elipse+CDT перекрывается QtCreator'ом, который для C++ из коробки лучше приспособлен. Ну а emacs разве что inetllisense по нормальному не умеет из всего этого)
bigfatbrowncat
23.08.2015 10:18-1который меня устраивал всем, кроме того, что в нем нельзя было работать без использования мыши
Вот этот аргумент меня всегда больше всего радовал. Чем не угодила мышь? Только не отвечайте мне, что с ней медленно. Попробуйте про медленность мыши рассказать вашему соседу-старкрафтеру :)
Я впервые услышал про «неудобную и медленную мышь» от человека, который был моим преподавателем информатики и который был старше моих родителей лет на 5-10. Он сам пользовался мышью так: клал на нее пальцы, пододвигал ее к нужному месту на экране, потом перекладывал палец на кнопку и торжественно (иначе не сказать) эту кнопку жал.
Еще я от него слышал, что для того, чтобы попасть мышью по кнопке так же ловко, как пальцем, надо, чтобы эта кнопка занимала четверть экрана. При его навыках владения этим инструментом, в его поколении, когда мышами можно было гвозди заколачивать, это простительно.
Разумеется, набор текста пальцами на клавиатуре быстрее, чем мышью на экранной клавиатуре. Но вот с человеком, который набирает текст одним пальцем, я бы посоревновался. А вы часто нажимаете больше двадцати хоткеев в минуту?
Лично я при написании программ процентов 80 времени думаю и процентов 20 — пишу. И нажать что-то мышкой (с которой я общаюсь с 12 лет, хотя до этого у меня был комп совсем без мышки) для меня гораздо проще, чем учить 100500 хоткеев.BelBES
23.08.2015 10:47В emacs не надо учить 100500 хоткеев, их можно настроить так, чтобы нажимать не задумываясь.
Ну и лично у меня в 80% разудмий входит еще изучение логов работы программы, написание мелких скриптов для их обработки на python/perl, написании заметок на основе полученных данных и тд и тп, т.ч. все равно в этой работе присутсвует процессинг текста.bigfatbrowncat
24.08.2015 14:58Согласен с вами. Вопрос был лишь в том, чем могла помешать мышь. Моё утверждение — ничем.
BelBES
24.08.2015 15:03+2Помешать — ничем, но без неё удобней.
bigfatbrowncat
24.08.2015 15:12В emacs не надо учить 100500 хоткеев
Я знаю порядка 20 горячих клавиш в eclipse. А если бы все функции, которые я там использую я делал с помощью хотев, пришлось бы знать около пятидесяти. Или ста.
Я не люблю писать консольные команда даже если это вим-овские ":blabla". Я даже :wq учил некоторое время, потому что GIT предлагает Vim в качестве стандартного редактора сообщений.
Моя голова забита совсем другими вещами.
Вообще, конечно, зря я в этот спор влез. Просто настроение было такое угрюмое.
Ответьте ровно н один вопрос: на какую функцию в eclipse, где на каждый чих переназначаемая горячая клавиша, НЕЛЬЗЯ назначить горячую клавишу? Назовите хоть одну.BelBES
24.08.2015 15:40Ну вот типичная ситуация: у меня программа выплевывает лог в консоль, после завершение программы я регуляркой хожу по логам и анализирую их. Все это я делаю не выходя из emacs и не отрывая пальцев от клавиатуры, в Eclipse я так смогу сделать?
bigfatbrowncat
24.08.2015 17:23Кхм… ну, допустим. Логи, конечно, можно парсить, если формат известен. А если у вас просто какой-то лог… Мне никогда не приходилось с ним делать что-то сложнее поиска.
Жму Ctrl+F7 (переход к окошку с консолью), затем Ctrl+F, ставлю галку «Regular expressions» (вот тут удобнее мышью, но она запоминается) — и вот у меня поиск в логе по регуляркам.
Это — оно?
webkumo
24.08.2015 19:54Если вы запустились из Eclipse, то и консоль (out) будет направлен в него. Если не из Eclipse — нужно будет как-то буфер перекидывать. Хотя тут могу ошибаться, но вроде это общее правило для основной тройки Java IDE (Idea, Eclipse, Netbeans).
PS опять же не уверен, что Eclipse этим занимается, но вот Idea ещё и подсветит знакомые классы в стектрейсе и позволит по клику переходить в точку вызова.bigfatbrowncat
25.08.2015 01:26-3Если вы запустились из Eclipse
Простите, а вы рассматриваете ситуацию, при которой приложение, разрабатываемое в IDE, запускается не из нее? Простите… а зачем вы так делаете? То есть мне кажется, что запустить изнутри можно абсолютно всегда, плюс отладчик автоматом цепляется…
Какой смысл запускать извне?
Idea ещё и подсветит знакомые классы в стектрейсе
Eclipse — тоже
bigfatbrowncat
24.08.2015 15:16Что до меня — то мне без разницы, какие гадкие использовать — родные или настроенные. Я через день забуду даже те, которые придумал сам.
Alexeyslav
24.08.2015 11:51+1У нас работают… те кто копировать-вставить вызывают из меню, мышкой. Но хоткеи им все равно не помогут.
ДА, некоторое количество часто употребляемых хоткеев все-таки необходимо выучить для эффективной работы.
Но я боюсь представить каковы требования к эффективности работы(ввода текста программы?) если для этого необходимо знать сотни хоткеев… И что это за настолько разнообразная работа.bigfatbrowncat
24.08.2015 15:09-2Я утверждал только то, что мышь — полезный инструмент при разработке. И идеология «надо всё делать без мыши» ущербна.
BelBES
24.08.2015 15:17+1И идеология «надо всё делать без мыши» ущербна.
И таки чем она ущербна не понятно. Вы её в полной мере пробовали, чтобы это утверждать?:)
Вот я и с мышкой N лет работал, потом без мышки и по личному опыту пришел к выводу, что без мыши лично мне удобней… как и многим другим пользователям emacs/vim.bigfatbrowncat
24.08.2015 15:30-1Вы меня не поняли.
Мое утверждение 1: eclipse поддерживает хоткеи для всего подряд. И в нем можно при желании работать на клавиатуре. Возможно, совсем без мыши обойтись не удастся, но 90% работы точно можно делать без нее, если это хочется. Также в нем можно настроить хоткеи по своему вкусу. Всё можно.
Мое утверждение 2: Vim не позволяет выбирать пункты из меню мышкой, тем самым навязывая пользователю стиль работы «keyboard-only», подходящий далеко не всем. К тому же, он предлагает свой совершенно шизофренический дизайн с двумя режимами «пикать и всё портить», перемещение по тексту клавишами, для этого не предназначенными и под всё это подводится теоретическая база (смехотворная, на мой взгляд), что передвиганное рук по клавиатуре занимает время, которое можно сэкономить.
Мое утверждение 3: навязывание ограничений пользователю говорит либо об ущербности системы, либо об ее недоработанности.
И еще одно соображение: если в чьей-то работе можно сэкономить заметное время за счет избавления от передвигания пальцев по клавиатуре, значит этот человек либо супермен (и тогда он достигнет успеха в любом редакторе текста), либо машинистка. Моя средняя скорость набора кода (если усреднять за целый день работы) составляет несколько десятков символов в минуту. И то, если день «задался».
Разумеется, я допускаю, что кому-то редакторы типа Emacs/Vim удобнее. Иначе бы не о чем было спорить. Я лишь хочу дать понять, что переход с них на полноценную IDE существенно вероятнее улучшит вашу эффективность, нежели наоборот.BelBES
24.08.2015 15:51+1Мое утверждение 2: Vim не позволяет выбирать пункты из меню мышкой, тем самым навязывая пользователю стиль работы «keyboard-only», подходящий далеко не всем. К тому же, он предлагает свой совершенно шизофренический дизайн с двумя режимами «пикать и всё портить», перемещение по тексту клавишами, для этого не предназначенными и под всё это подводится теоретическая база (смехотворная, на мой взгляд), что передвиганное рук по клавиатуре занимает время, которое можно сэкономить.
Vim-стиль с модальным редактированием мне тоже не особо нравится, мне больше нравится иметь возможность сделать все что в голову взбредет прямо сейча.
Мое утверждение 3: навязывание ограничений пользователю говорит либо об ущербности системы, либо об ее недоработанности.
В emacs нет ограничений, им можно пользоваться как обыкновенным редактором, орудуя мышкой+клавиатурой если так больше нравится) А вот у большинства IDE есть предел, выше которого под себя настроить среду уже нельзя и придется привыкать к тому, что есть.
Я лишь хочу дать понять, что переход с них на полноценную IDE существенно вероятнее улучшит вашу эффективность, нежели наоборот.
Практика показывает, что мало кто в качестве первого редактора кода использует vim/emacs. Подавляющее большинство переходит на такие редакторы с тяжелых IDE. Вы и правда считаете, что все эти люди — городские сумасшедшие, которые переходят на подобные редакторы в ущерб удобству?bigfatbrowncat
24.08.2015 15:58-1Вы и правда считаете, что все эти люди — городские сумасшедшие, которые переходят на подобные редакторы в ущерб удобству?
А вот с этого места я бы уточнил.
Я видел студентов, которые, ползав пару недель eclipse в учебном проекте и не изучив и десятой части его возможностей, бросали его со словами «да ну его, он кривой».
Видел людей, которые писали на python и использовали при этом sublime. На мой вопрос, чем не угодил PyCharm, ответ был либо «да ну его, он тяжелый/сложный», либо «хрен знает, не пробовал».
Я видел около сотни разработчиков, которые писали на Java проекты по несколько десятков или сотен классов. Все они использовали Idea или Eclipse. Многие в совершенстве владели Vim-ом. Ни одному из них даже в кошмаре не могло бы присниться, чтобы редактировать Java-код не в IDE.
Из этого я сделал вывод о том, что во-первых, мало знаю пижонство на больших проектах (думаю, там картина схожая, хотя допускаю, что PyCharm хуже, чем Idea), а во-вторых, не встретив ни одного человека, ушедшего с хорошо известной ему IDE на что-то другое только из-за возможности никогда не браться за мышку, склонен полагать, что таких людей исчезающие мало. И я бы с радостью пообщался с таким — очень интересны его соображения.
Кстати, одно время действительно приходилось редактировать большие Java-проекты без IDE. Это было когда памяти в компе было еще 1 Гигабайт, а Эклипс под проект хотел съесть 800 Мегов. Вот тогда приходилось «изгаляться» — грузить частями, подкладывать jar-файлы… Но те времена уж лет 5 как минули.
asm0dey
24.08.2015 17:25+3Я в идее никогда не берусь за мышку, кстати. 6 лет коммерческой разработки на Java.
bigfatbrowncat
24.08.2015 17:32Снимаю шляпу. :) У вас память хорошая. Только вы это не мне говорите, а товарищам, которые Vim защищают, потому что, якобы, в IDE нельзя обойтись без мыши.
asm0dey
24.08.2015 21:02Ну в виме я тоже мышкой не пользуюсь, но использовать его для чего-то серьёзного?…
webkumo
24.08.2015 15:35+1Вот и начните с этой фразы «без мыши лично мне удобней». Всё остальное — профанация.
Я вот пользуюсь и мышью и клавиатурой. Иногда для одних и тех же действий (вплоть до выбора файла в окошке). Всё зависит от текущего контекста — держусь за мышку, значит мышкой поконтролю, держусь за клавиатуру и скать долго до фейла не придётся — буду работать с клавиатурой.BelBES
24.08.2015 15:44Так я вообще не утверждал, что всем без мыши удобней, это меня тут пытаются убедить в том, что работа без использования мыши ущербна)
з.ы. в emacs таки при желании можно и мышкой тыкать, менюшки и прочие свистелки упрощающие жизнь любителям этого контроллера присутствуют)bigfatbrowncat
24.08.2015 15:45в emacs таки при желании можно и мышкой тыкать, менюшки и прочие свистелки упрощающие жизнь любителям этого контроллера присутствуют)
Видел. Вот там они и вправду очень неудобные. Такой уж у него UI.BelBES
24.08.2015 15:53Просто подавляющее большинтво пользователей emacs не пользуются его GUI, потому никто и не озадачивался его улучшением)
bigfatbrowncat
24.08.2015 17:24-1… из чего я и сделал вывод, что для чего-то не клавиатурно-основанного он не приспособлен.
bigfatbrowncat
24.08.2015 15:44-1Что — профанация? Какой смысл спорить о том, что удобнее лично вам? Я, может, левой ногой на тачскрине код ввожу. Мне, может, так думается лучше…
Спорить можно о статистике. И об эффективности.
Люди, которые утверждают, что новичка-программиста следует обучить Vim-у и тогда он будет ужас как эффективен, неправы. Это разве профанация?
Люди, которые считают, что Emacs лучше, потому что в нем плагин пишется за 10 минут, неправы, потому что плагин должен писаться не тем же самым человеком, который его использует, а совсем другим. И только при таком разделении труда работа пойдет эффективно.
И, наконец, люди, которые считают, что при увеличении проекта его будет так же легко контролить в Emacs, как в Eclipse, неправы. Они, очевидно, просто не имели дело с по-настоящему крупными проектами. И просто смущают умы начинающих, перед которыми стоит выбор, какую среду разработки изучать и которым может обманчиво показаться, что текстово-консольный интерфейс симпатичнее, а значит — удобнее.
держусь за мышку, значит мышкой поконтролю
Вот тут я с вами абсолютно согласен. Но ведь и спорил я не с вами.BelBES
24.08.2015 16:01И, наконец, люди, которые считают, что при увеличении проекта его будет так же легко контролить в Emacs, как в Eclipse, неправы. Они, очевидно, просто не имели дело с по-настоящему крупными проектами.
На 700K строк кода в ~3500 файлах — это достаточно крупный проект? Если да. то могу заверить, что в emacs полет нормальный :)bigfatbrowncat
24.08.2015 16:06-1Ну, как скажете. Я бы так не смог. И не посоветовал бы никому. Разве только альтернатив никаких нет.
BelBES
24.08.2015 16:10Альтернативы есть разумеется, до этого я пользовался QtCreator'ом (т.к. под linux это пожалуй самая адекватная IDE для C/C++)… в итоге перешел на emacs, таки ради того, чтобы не прыгать по окнам между IDE/консолью/файл-браузером/редактором для скриптов и чтобы не пользоваться мышкой.
bigfatbrowncat
24.08.2015 16:48Можно в Emacs переименовать переменную или класс по контексту?
Или, хотя бы, осуществить контекстный поиск: пусть у меня в одном файле есть двадцать переменных «iter» в разных функциях — я могу получить список вхождений КОНКРЕТНОЙ из них, который не включает остальные, основывается на реальном парсинге кода, а не на регулярках, и шагать по нему?
Можно написать (хрен с ним, пусть с клавиатуры) что-то типа «add watch», чтобы потом, идя по коду отладчиком, видеть значение переменной в окошечке сбоку?
А как делается навигация типа «Ctrl+Click», то есть прыжок к декларации? И работает ли он для переменных, а не только для классов?
Это — список фич, без которых я бы работать нормально не смог. Это всё уже есть?
А вызвать дерево вызовов функции (функции, которые вызывают функции, которые вызывают эту функцию) можно?
А можно такое же дерево для наследования классов?DrLivesey
24.08.2015 17:11Или, хотя бы, осуществить контекстный поиск: пусть у меня в одном файле есть двадцать переменных «iter»
Конкретно это (Find all references) в MSVS из коробки работает не то что бы очень хорошо. Вываливает все что есть в солюшене без разбора. Возможно, я неправильно пользуюсь.bigfatbrowncat
24.08.2015 17:25-2MSVS — худшая из известных мне IDE для C++. Какой смысл о ней вообще говорить? Я знаю и люблю Eclipse. Там это работает прекрасно.
DrLivesey
24.08.2015 17:32Смысл говорить об MSVS возникает тогда, когда проект построен именно в ней.
Есть ли в Eclipse «Parallel Stacks» окно в дебаггинге? В 13й студии очень помогает при дебаге мультитрединга.bigfatbrowncat
24.08.2015 17:35Честно говоря, не знаю. Есть расширения для параллельной отладки… Вот: help.eclipse.org/kepler/index.jsp?topic=%2Forg.eclipse.ptp.doc.user%2Fhtml%2F06parDebugging.html
Но, думаю, это не совсем то, о чем вы говорите.
vlivyur
27.08.2015 11:13В 14 версии переделали, теперь гораздо удобнее (декларация отдельно и все обращения именно к этой декларации ветками к ней, если где-то переопределена, то это будет новый корень со своими ветками).
BelBES
24.08.2015 17:12+1Можно в Emacs переименовать переменную или класс по контексту?
Или, хотя бы, осуществить контекстный поиск: пусть у меня в одном файле есть двадцать переменных «iter» в разных функциях — я могу получить список вхождений КОНКРЕТНОЙ из них, который не включает остальные, основывается на реальном парсинге кода, а не на регулярках, и шагать по нему?
С семантическим анализом кода в emacs действительно не все хорошо. Для C++ есть semantic и какие-то моды. работающие через clang, но я ими не пользуюсь, т.к. они кривые. Мне вполне хвает для этих операций grep'а.
Можно написать (хрен с ним, пусть с клавиатуры) что-то типа «add watch», чтобы потом, идя по коду отладчиком, видеть значение переменной в окошечке сбоку?
Есть неплохой фронтенд к gdb, по моему даже лучше, чем в QtCreator.
А как делается навигация типа «Ctrl+Click», то есть прыжок к декларации? И работает ли он для переменных, а не только для классов?
Тотже ctags или semantic есть, народ пользуется, но лично я как-то и без этого обхожусь.
А вызвать дерево вызовов функции (функции, которые вызывают функции, которые вызывают эту функцию) можно?
А можно такое же дерево для наследования классов?
Вероятно как-то можно, но мне хватает grep'а для таких вещей.bigfatbrowncat
24.08.2015 17:27Ну как?.. Скажите мне, КАК вы умудряетесь ориентироваться в проекте на 3500 файлов без семантического поиска/навигации? Что вы в нем делаете? Я не понимаю. Может, я правда дурак и мозги у меня сушеные.
Я без быстрой и качественной навигации буду только разбираться в связях в таком проекте две недели…BelBES
24.08.2015 17:50Основной инструмент для поиска по коду у меня — это grep (ну и GDB, если хочу посмотреть помимо прочего, какие данные куда передаются), а всю семантику проекта я в голове держу.
На самом деле при некоторой сноровке grep'ом получается ходить по проекту довольно быстро. Хотя, будь в emacs качественно реализованный семантический парсер, я бы им пользоваля.bigfatbrowncat
28.08.2015 20:10Основной инструмент для поиска по коду у меня — это grep
Я слишком избалован, чтобы при редактировании кода лезть в консоль всякий раз, когда мне понадобится найти слово. Тем более, что просто найти слово — не фокус в любом редакторе. Я имел в виду именно семантический поиск. Неоднократно сталкивался с Java-проектами, в которых класс с одним и тем же именем присутствует в разных пакетах.BelBES
28.08.2015 21:29Я слишком избалован, чтобы при редактировании кода лезть в консоль всякий раз, когда мне понадобится найти слово.
Так в emacs не надо никуда лезть, один хоткей и вот ты уже грепаешь)
Я имел в виду именно семантический поиск. Неоднократно сталкивался с Java-проектами, в которых класс с одним и тем же именем присутствует в разных пакетах.
Ну, я в основном пишу на C++, Python и т.д. и очень редко пишу на Java, т.ч. мне грепа вполне хватает.
n0dwis
21.08.2015 00:58Просто воспринимайте емакс как конструктор текстового редактора
Если продолжить аналогию с конструктором.
Из лего можно собрать молоток. Он будет похож на молоток. Им можно будет по чему-то удалить. Но вот молотком он не будет и гвозди на стройке забивать не сможет.
Вот я и не уверен, что емакс даже со всеми настроенными плагинами когда-либо сможет дать то же удобство и скорость, что и IDE.BelBES
21.08.2015 08:39+1У emacs есть архитектурный недостаток — он однопоточный и асинхронность там добавляется через одно место, поэтому emacs умеет подвисать выполняя простейшие операции типа коментирования кода, если выделенный фрагмент достаточно большой. Вот эта однопоточность не позволяет реализовать большинство функционала IDE.
Flammar
21.08.2015 10:46Если продолжить аналогию с конструктором.
Если было бы надо, то, думаю, давно сделали бы специальные детали с твёрдыми вставками и с тяжёлыми вставками…
Из лего можно собрать молоток.
Kotyamba
20.08.2015 23:12+2Для проектов использую IDE (PyCharm, WebStorm, XCode). Для просмотра исходников и просто редактирования файлов и текстов использую SublimeText. Vim использую только удалённо на серверах. Хотел перейти на просто редакторы, Vim и SublimeText, но как верно заметил автор, на работе, времени нет искать откуда «ноги растут», cmd+click и уже в нужном месте.
SDSWanderer
21.08.2015 00:08Клик, затем F12 в Sublime Text 3 из коробки.
Kotyamba
21.08.2015 09:34В javascript проекте работает и то не везде и через раз. Если посмотреть где была объявлена переменная то не работает. А в python/django проекте так вообще ничего не работает.
Alexey2005
21.08.2015 00:02+4IDE в некотором роде выполняют ту же функцию, что и фреймворки. Да, можно взять и написать всё с нуля. У опытного программиста код получится красивее, меньше, производительнее. Однако гораздо проще и в разы быстрее взять фреймворк.
То же и с IDE. Да, можно взять редактор и законфигурировать его под IDE самостоятельно, по сути занимаясь написанием собственной IDE на базе текстового редактора. У опытного программиста при неограниченном запасе времени получится не хуже. Но гораздо проще взять уже готовую IDE и не заниматься велосипедостроением.
Наличие мощных фреймворков, библиотек и IDE — один из важнейших критериев юзабельности языка программирования. Если для нового распиаренного ЯП предполагается писать код в ST, а враппер для DirectX генерировать ручками (т.к. ни либ, ни фреймворков), то при наличии выбора целесообразнее не гнаться за модой, а обратиться к проверенному решению, где вам не придётся создавать с нуля всю инфраструктуру.bigfatbrowncat
22.08.2015 03:20У опытного программиста при неограниченном запасе времени получится не хуже.
Как человек, в данный период своей жизни занимающийся анализом кода IDE, ответственным за синтаксический анализ кода введенной программы, ответственно заявляю: туда вложены тысячи (если не десятки тысяч) человеко-часов. И в Eclipse, и в Idea. И у самого опытного программиста, если он один, на это уйдет полжизни.
BelBES
21.08.2015 00:37+2По моему, единственная проблема редакторов типа Emacs, Vim, из-з которой они проигрывают в некоторых аспектах полноценным IDE, состоит в том, что большинство расширений довольно кустарного качества, а часть функционала полноценных IDE вообще не реализовано (типа того-же пресловутого автокомплита).
При этом никто особо не торопится вкладываться в качественную доработку этих редакторов до состояния IDE, вместо этого выпуская 100500-ю IDE на базе кривой эклипсы.
beeruser
21.08.2015 07:15YouCompleteMe и taglist.vim вполне делают псевдо-IDE из вима при желании.
BelBES
21.08.2015 08:37+1В emacs тоже поидее есть clang-autocomplete, ctags и другие плагины для получения IDE из редактора… но все эти плагины некачественные и только замедляют работу, т.к. периодически что-то в них глючит. В итоге из всех автокомплитов я остановился на самом тупом, который дополняет словами из открытых буферов, а по проекту хожу grep'ом…
saggid
21.08.2015 00:45Не знаю, я и в Нетбинсе своём прекрасно живу десятки минут без единого переключения своих рук к мыши. Немного поднастроил стандартную раскладку горячих клавиш (буквально пару штук), выучил остальные полезные комбинации — и нормально как-то живётся. Вообще, я очень привык ко многим фишкам Нетбинса, и не вижу здесь ничего зазорного: наоборот это показатель того, что ты научился использовать свою IDE на полную мощь.
Это, например, такие функции, как поиск какого-то вхождения по всему проекту, при этом, когда ты находишься на одном из результатов поиска, нажатие Ctrl+< и Ctrl+> переключает тебя между предыдущим и следующим результатами. Особенно это помогает, когда тебе надо прошерстить штук 100 найденных позиций в коде и проанализировать каждую из них. Ну как в такие моменты не полюбить Netbeans?
И это всё — из коробки, удобно настроенное, прекрасно работает. Ну и зачем мне какие-то редакторы с, теоретически, немного более высоким уровнем гибкости? Ради понтов? Я не считаю разумным тратить столько своего времени только ради того, чтобы потом понтоваться своим супер-редактором перед другими людьми. Лучше ведь понтоваться перед ними своими крутыми проектами, как думаете? )
toxicmt
21.08.2015 01:08Мы в hexlet.io переодически проводим вебинары и один из последних был как раз про vim www.youtube.com/watch?v=79OWQ1qJwto.
Основная идея в том что vim это слепой десятипальцевый способ редактирования текста и его мощь именно в командном режиме. Попытка смотреть на него как на IDE уводит от сути и всегда плагины вима будут недотягивать до автоматизации, которая есть практически в любой иде. Но это вторично по отношению к тому за что его по настоящему любят и пользуются им.js605451
21.08.2015 01:22+3Программистам платят за программирование, а не редактирование текста. А программирование это:
1. Изучение существующего кода и зависимостей между разными его частями: навигация по цепочкам вызовов буквально с одного конца проекта в совершенно другой.
2. Отладка либо самого приложения, либо падающих тестов: расстановка брейкпоинтов, разглядывание стека вызовов, и прочее.
3. Упорядочивание структуры кода после внесения очередных изменений: начиная с переименования всяких сущностей в коде и заканчивая перекладыванием одних директорий в другие.
4. И да, иногда ещё редактирование текста.
Совершенно не понимаю, почему всех так тянет почти-отождествлять «удобный процесс программирования» и «удобное редактирование текста». Программа — это нифига не текст. Это текст, оформленный очень определённым образом. Глупо не пользоваться этим нюансом.Miklos
21.08.2015 01:34+1Так же глупо как отказываться от удобного редактирования текста, а код это всё-таки текст.
Этот холивар очередное скатывание в райности. По мне так все эти вещи (высокоуровненое редактирование — автокомплиты/анализаторы в ide и низкоуровневое — vim) очень хорошо дополняют друг друга.js605451
21.08.2015 01:42Можете раскрыть тему «низкоуровневого редактирования»?
Miklos
21.08.2015 01:48+2Непосредственно работа с текстом. Вим позволяет быстро перемещаться/редактировать текст не убирая рук с клавиатуры (причём не уходя на стрелки).
js605451
21.08.2015 02:15+1Я предпринимал несколько попыток изучить Vim хотя бы на уровне «просто редактирования текста» — без всяких там плагинов и прочего хардкора. Очень удивило, что все туториалы сводятся к решению задач типа «прыгнуть на 3 слова влево и оказаться на первом символе первого слова» или «прыгнуть на строчку 192». Никогда в жизни у меня не было практической задачи «прыгнуть на 3 слова влево». У меня вообще нет привычки считать слова, поэтому я могу видеть куда мне надо попасть, но я понятия не имею сколько у меня слов от курсора до того места. Я не могу вспомнить ни одного файла, про который смог бы рассказать что там находися на какой-то строчке. Действительно кто-то может это запомнить? С другой стороны я совершенно точно знаю, что до тех пор, пока я _итеративно_ двигаю курсор куда-то в сторону куда мне нужно, и вижу, что он туда движется, в какой-то момент я смогу сделать усилие над собой и остановиться оказавшись в нужном месте.
Вы можете привести какой-то практический пример в контексте программирования, когда «попсовый» подход однозначно проигрывает у Vim? Только чтоб не экзотическая задача, которая возникает раз в год, а какое-то базовое действие, которое нужно повторять по несколько раз в день?Delphinum
21.08.2015 02:30Никогда в жизни у меня не было практической задачи «прыгнуть на 3 слова влево»
А задачи замены всего содержимого текущего тега, или значения атрибута тега, или выравнивания тела функции, или может замены текущего слова?js605451
21.08.2015 02:48+3всего содержимого текущего тега, или значения атрибута тега
Универсальное решение для замены куска текста: иду в начало, зажимаю Shift, иду в конец, начинаю писать новое содержимое, старое при этом удаляется. Ходить в начало и в конец можно по-разному — зависит от того сколько в нынешнем содержимом строчек, где именно это содержимое начинается. От банального Home, до Ctrl+Left много раз, до банального челябинского Ctrl+A.
выравнивания тела функции
Есть какая-то кнопка для этого и в Visual Studio и в IDEA. Очень редко ей пользуюсь, т.к. обе среды при написании кода сами расставляют все отступы, а при вставке совершенно левого кода тут же его форматируют.
замены текущего слова
Что-то типа Alt+Shift+Up и начать писать новое слово (в IDEA по крайней мере).Delphinum
21.08.2015 03:52+2Универсальное решение для замены куска текста
Жмякаете dit, удаляете содержимое тега. Есть еще сочетания для удаления всего между {}, [], <>, "", и т.д.
а при вставке совершенно левого кода тут же его форматируют
Да, прекрасная возможность. К сожалению у меня не всегда оно работало.
Что-то типа Alt+Shift+Up и начать писать новое слово
Слово, предложение, блок обрамленный чем либо и т.д.js605451
21.08.2015 04:15-3Жмякаете dit, удаляете содержимое тега. Есть еще сочетания для удаления всего между {}, [], <>, "", и т.д.
Т.е. замечательно работает для HTML, CSS, C, C++, Java, C#, JavaScript, JSON, XML но вот для Python, JADE и YAML придётся использовать какой-то абсолютно другой подход, потому что там таких явных маркеров начала и конца (тела функции например) просто нет. Возникает небольшое смущение: вроде задача «заменить содержимое блока» есть буквально везде, но решения для этой задачи в Vim будет отличаться для разных языков. Т.е. ваше dit совершенно замечательное, но нифига не универсальное.
Слово, предложение, блок обрамленный чем либо и т.д.
У меня в коде нет предложений. Блоки обрамлённые чем либо тоже не всегда есть — выше привёл примеры.Delphinum
21.08.2015 23:47Т.е. ваше dit совершенно замечательное, но нифига не универсальное
Не, она будет работать хоть в LaTeX, если вы засуните туда теги.
У меня в коде нет предложений
Заменим понятие: предложение — строкаjs605451
22.08.2015 14:36Не, она будет работать хоть в LaTeX, если вы засуните туда теги.
У меня нет опыта с Latex. Покажите пожалуйста как это будет выглядеть для Python — там нет очевидной симметрии у начала и конца блока.
Заменим понятие: предложение — строка
Home, Shift-End, начать что-то писать. Ну или наоборот — End, Shift+Home.Delphinum
22.08.2015 21:43Покажите пожалуйста как это будет выглядеть для Python
Ну тег он и в африке тег. Если вы имеете ввиду блоки, то для Python оно работает на основе отступа, если я не ошибаюсь.
Home, Shift-End, начать что-то писать. Ну или наоборот — End, Shift+Home
Да, я сам раньше удивлялся, как же быстро я нажимаю эти комбинации, пока не перешел на Vim. Там есть комбинация Shift+s, она оказалась побыстрее.
Miklos
21.08.2015 02:34+3Я тоже не понимаю этих примеров с подсчётом слов и строк.
Строки у меня сами считаются
PerlPower
21.08.2015 02:10+1Помимо разработки enterpise систем на java/.net есть еще широкий класс задач. Там перечисленные вами факторы не так важны как удобное редактирование текста и гибкость. Например среди Java и .Net программистов пользователей редакторов единицы, среди веб-программистов тех, кто жалует редакторы уже гораздо больше.
js605451
21.08.2015 02:25У меня 2 вопроса:
1. Что такое enterprise и почему вы его как-то отделяете от остального программирования?
2. Что такое веб-программисты и почему вы их отделяете от Java/.NET программистов?
Дисклеймер: я уже год в проекте с бэкендом на Java (enterprise?) и фронтэндом на Angular (веб?). Действительно пишу бэкенд в IDEA, а фронтэнд — в редакторе. Ответ на вопрос «почему?» очень простой: потому что я не хочу ломать психику завставляя себя понять, что когда я пишу Java — куча плюшек от IDE есть, а когда JavaScript — про плюшки можно забыть. Типа «видишь Atom — забудь про Alt+Shift+R».PerlPower
21.08.2015 03:02+31. Что такое enterprise и почему вы его как-то отделяете от остального программирования?
Там попадаются огромные старые проекты, которые часто написаны черти как и рефакторить приходится целыми подсистемами, с IDE это проще. Программисты там часто берутся из разряда подешевле и побольше — значит им нужно поставить IDE которая будет бить их по рукам, и которая не даст сломать процесс, и которая будет заботливо расставлять пропущенные запятые, показывать что вместо = тут должно быть ==, что переменная не используется и т.п… Поддержка таких систем часто подразумевает именно поддержку — новые фичи добавляются мало, больше рефакторинг и багфиксинг. В энтерпрайзе часто бывает моделирование предметной области на десятки и сотни классов, с такой структурой проще работать в IDE, особенно менять такую структуру.
2. Что такое веб-программисты и почему вы их отделяете от Java/.NET программистов?
Те кто пишут для веб на PHP, JS, Python, Ruby. Отделяю потому что другая специфика работы, несмотря на то, что писать для веба можно и на Java и на .Net.js605451
21.08.2015 03:51+1Вот это:
рефакторить приходится целыми подсистемами, с IDE это проще.
и это:
Программисты там часто берутся из разряда подешевле и побольше
друг другу очень сильно противоречит. Программисты «подешевле и побольше» — это как раз те, от кого код достался в наследство. Программистов с хорошими скиллами рефакторинга — один на сотню и они совершенно точно «подороже».
им нужно поставить IDE которая будет бить их по рукам, и которая не даст сломать процесс, и которая будет заботливо расставлять пропущенные запятые, показывать что вместо = тут должно быть ==, что переменная не используется и т.п…
Снова удивлюсь и не соглашусь. В чём героизм напрягать мозг на рутину типа «переменная _теперь_ не используется и её можно удалить»? Любая работа, которую может делать компьютер, должна делаться компьютером. Компьютер вполне может за меня построить граф всех зависимостей всех классов/методов в проекте и рассказать мне какие классы или методы нигде не используются.
Те кто пишут для веб на PHP, JS, Python, Ruby.
Нет там никакой специфики — везде одно и то же: есть требования, которые нужно выполнять, есть код, который при этом нужно писать, есть тесты, который тоже нужно писать, чтобы получить минимальную уверенность, что всё работает как нужно. И да, в любой программе на любом ЯП рано или поздно возникает момент, когда понимаешь, что какие-то части реализации нужно переделать, чтобы сделать последующие изменения возможными — и вот здесь полноценная IDE помогает порубить всё налево и направо ничего не сломав, а редактор продолжает по-хипстерски подсвечивать синтаксис какой-нибудь темой Monokai намекая, что раз надел кеды и работаешь из кафешки, придётся всё делать руками.PerlPower
21.08.2015 04:39друг другу очень сильно противоречит. Программисты «подешевле и побольше» — это как раз те, от кого код достался в наследство. Программистов с хорошими скиллами рефакторинга — один на сотню и они совершенно точно «подороже».
Подсистемы рефакторят тимлиды с JIdea Ultimate Edition, всякую мелочевку делают толпы рядовых на JIdea Standard Edition. Никаких противоречий — разные роли в одной компании.
Снова удивлюсь и не соглашусь. В чём героизм напрягать мозг на рутину типа «переменная _теперь_ не используется и её можно удалить»? Любая работа, которую может делать компьютер, должна делаться компьютером. Компьютер вполне может за меня построить граф всех зависимостей всех классов/методов в проекте и рассказать мне какие классы или методы нигде не используются.
Ничего не писал про героизм, просто хотел обратить внимание, что у джуниоров часты ошибки в базовых вещах и применение IDE для коррекции ошибок такого рода оправдано.
Нет там никакой специфики — везде одно и то же: есть требования, которые нужно выполнять, есть код, который при этом нужно писать, есть тесты, который тоже нужно писать, чтобы получить минимальную уверенность, что всё работает как нужно.
Если уж абстрагировать до такой степени, то давайте сразу и доабстрагиуремся до того, что программирование в конечном счете — это редактирование текста. А навскидку — в вебе существует гораздо больший зоопарк технологий, который IDE поддерживать просто не успевают. Всякие тесты и CI распространены в гораздо меньшей степени, чем в явамире. Возможны сложные тестовые окружения, где приходится логиниться в настроенную сеть и там писать код в vim/emacs.
И да, в любой программе на любом ЯП рано или поздно возникает момент, когда понимаешь, что какие-то части реализации нужно переделать, чтобы сделать последующие изменения возможными — и вот здесь полноценная IDE помогает порубить всё налево и направо ничего не сломав, а редактор продолжает по-хипстерски подсвечивать синтаксис какой-нибудь темой Monokai намекая, что раз надел кеды и работаешь из кафешки, придётся всё делать руками.
Вот когда такой момент наступает можно и запустить IDE. Но вообще согласитесь, что фиксить/дописывать код приходится чаще, чем ломать архитектуру. Если нет, то у вас специфичный проект. И думаю многим было бы интересно про него услышать.js605451
21.08.2015 13:27+1Если уж абстрагировать до такой степени, то давайте сразу и доабстрагиуремся до того, что программирование в конечном счете — это редактирование текста.
Не соглашусь. Программирование — это в первую очередь осознание структуры решения, и только во-вторую — перенос этого осознания в текст. Осознание структуры — это, ИМХО, процентов 90% от всей задачи. Совершенно нормальна ситуация когда 4 часа изучаешь существующий код и тесты к нему, а потом за 20 минут делаешь все нужные правки.
А навскидку — в вебе существует гораздо больший зоопарк технологий, который IDE поддерживать просто не успевают.
Аналогичную мысль я высказывал где-то выше в этом топике — из-за специфики JavaScript нормальная IDE просто невозможна. Та IDE, которая возможна, не будет отличаться от редактора с парой плагинов.
Всякие тесты и CI распространены в гораздо меньшей степени, чем в явамире.
Вы очень неправы — в мире JavaScript есть огромное количество тестовых фреймворков и сопутствующих библиотек на любой вкус и цвет. Есть куча решений для написания тестов в контексте реальной среды исполнения — начиная от Karma, которая гоняет тесты в настоящем броузере и заканчивания Protractor для Angular, который позволяет вообще всё решение полностью запустить, понажимать кнопочки и убедиться, что приложение ведётся себя как ожидается. Про CI не знаю что вы имеете в виду: то что весь опенсорсный JavaScript гоняет тесты на Travis и любит вставлять беджики со статусом билда в README на гитхабе — это факт. А как именно новые билды попадают в репозитории — уже второстепенный вопрос. Обычно либо через тот же Travis, либо какой-то одной командой grunt, которую _при желании_ можно точно так же выполнять через Travis.
Wedmer
21.08.2015 01:29+1Let Mortal Kombat begin.
Вот этой фразы точно не хватает. Есть такая поговорка «О вкусах не спорят», кому удобно работать в интегрированной среде, кому «просто в редакторе», хотя некоторые простые редакторы через расширения становятся как раз уже интегрированной средой разработки.bigfatbrowncat
22.08.2015 03:31Проблема в том, что это — не спор о вкусах. Есть люди, которым нравится одно, есть люди, которым нравится другое. И эти группы различаются не только предпочтениями в выборе редактора. У них разная область деятельности, они решают разные задачи. Для одних из этих задач годится один инструмент, для других — другой. Вот, один товарищ выше писал, что ему надо было редактировать файл под 100 мегабайтов и он его смог только в Vim загрузить. При этом сторонники IDE не пытались его переубедить в том, что этот файл откроется где-то еще.
Но как только заходит речь о том, что редакторы слабее и хуже при разработкекрупных проектов
, большинство их сторонников встают на дыбы и начинают «рыть землю» на предмет «вы просто не умеете ими пользоваться», вместо того, чтобы мирно признать, что их проекты просто меньше, чем те, в которых работают на IDE. Это же удар по самолюбию — вроде как несерьезное дело делаешь…
Вот оттуда, как мне кажется, и пошел спор. IDE не сделает новичка экспертом. Vim — тем более не сделает. Эксперта отличает умение подбирать инструмент под задачу и спектр владения этими инструментами. Я Vim плохо знаю и терпеть ненавижу за его избыточную сложность и непохожесть на вс на свете. Но если черт меня дернет открыть файл на 100 мегов, открою в нем. Потому что он это делает лучше всех.DrLivesey
22.08.2015 12:48+1Эксперта отличает умение подбирать инструмент под задачу и спектр владения этими инструментами
Мне кажется, что это самое правильное из всего сказанного в комментах.
Лично я пользуюсь на данный момент связкой Vim + MSVS (для С++).
Vim, отчасти моя вкусовщина (имеет место быть), но в нем я быстро пишу новый код.
Объяснить могу отчасти тем же автодополнением — дополняются только слова в открытых буферах. Когда я описываю новый класс мне далеко не всегда нужны все определения во всех хедерах. Мне нужен очень сильно ограниченный набор. В MSVS то же самое автодополнение иногда требует набрать имя локальной переменной чуть менее чем полностью, что крайне раздражает.
Когда класс определен — в дело вступает MSVS ибо отладка кода в ней реализована хорошо. И в целом, это меня устраивает, так как решает нужную мне задачу.Wedmer
22.08.2015 12:52+1Именно поэтому в qtcreator есть режим «FakeVim».
DrLivesey
22.08.2015 16:01+1С qtcreator я не знаком, но пытался в какой-то IDE для Python включить режим Vim в редакторе. Все было бы здорово кроме того, что режим работает несколько отлично от настоящего Vim на уровне базовых действий (работа с выделенным текстом и т.д.) что делает этот режим бесполезным. Да и в целом, я сомневаюсь, что кто-то бы стал полностью воспроизводить функционал Vim в IDE.
Wedmer
23.08.2015 00:17Ну так пользуйтесь чистым Vim. Он таки вполне расширяется до IDE. Причем даже под виндой.
Но на вашем месте я все таки бы глянул свежий qtcreator, может и понравится.
Раздел документации про режим FakeVimDrLivesey
23.08.2015 10:43+1Ну так пользуйтесь чистым Vim. Он таки вполне расширяется до IDE.
Насколько расширяем Vim, я знаю. Даже плагин к нему написал в борьбе за чистоту форматирования кода.
MSVS я сейчас пользуюсь по простой причине — я не единственный человек в команде и весь проект написан в ней. К тому же, в ней есть очень крутая фича Parallel Stacks для отладки многопоточного кода.
QtCreator при первой же возможности попробую.
ffriend
22.08.2015 16:25+2вместо того, чтобы мирно признать, что их проекты просто меньше, чем те, в которых работают на IDE. Это же удар по самолюбию — вроде как несерьезное дело делаешь…
CPython — почти миллион строк кода и 25 лет разработки. Это достаточно большой проект? Однако же Гвидо всё ещё пишет его в Vim/Emacs и недолюбливает Eclipse.n0dwis
23.08.2015 00:51-1Мне кажется, тут дело именно в CPython.
C — это набор функций и много глобальных переменных. Я утрирую, но всё-таки. Здесь нет областей видимости и других прелестей ООП, поэтому IDE не раскроет себя на 100%.
Да твит довольно двусмысленный, и очень хорошо перекликается со статьёй.ffriend
23.08.2015 02:07А каким боком области видимости влияют на возможности IDE? Проанализировать include-ы ничуть не сложнее, чем проанализировать import-ы, а C — синтаксически достаточно простой язык, в разы проще той же Scala, например.
Так или иначе, это только один из примеров одного известного человека. А есть целые сообщества и даже компании, которые уходят с тяжеловесных IDE на что-то более простое и кастомизируемое. Например, посмотрите на Atom от GitHub-а — они его явно не от безделия создали. Или на сообщество языка Julia, где главный рекоммендуемый редактор — Juno — построен на LightTable. Ну или на R, где основная альтернатива — это либо Emacs+ESS, либо RStudio, которая тоже мало чем отличаетя от блокнота со встроенным REPL-ом. Примеров — сотни.n0dwis
23.08.2015 10:20Дело не способностях IDE, а в удобстве использования того, что она может предложить в этом случае. Скажем, выдаст она в автодополнении 1000 вариантов названий функций. Это не сильно будет отличаться от того, что может предложить редактор.
ffriend
23.08.2015 16:12Скажем, выдаст она в автодополнении 1000 вариантов названий функций
Это если вы попросите её показать вообще весь список доступных в этом месте функций?
2-3 символов обычно вполне хватает, чтобы сократить список до вполне разумных пределов.
BelBES
23.08.2015 10:53RStudio — это такая вполне себе IDE)
А вот Emacs + ESS я что-то так и не понял зачем оно надо…ffriend
23.08.2015 16:16Так а что в ней есть от «настоящих IDE»? ) Вроде адских инструментов для рефакторинга нет? Визуализация графиков? Так она и в чистой консоли есть. Дебаггер? Ну может быть, но вроде как REPL его вполне неплохо заменяет.
Чисто из интереса, а чего вам в Emacs + ESS не хватает, что есть, например, в той же RStudio?BelBES
24.08.2015 10:19Мне сложно представить себе проект на R, де потребуется сложный рефакторинг) Ну дебагер есть, редактор есть, плюс всякие удобности типа вывода графиков и т.п… чем не IDE)
Может я как-то не так настраивал ESS, но я не понял, чем он вообще отличается от консольного интерфейса R)ffriend
24.08.2015 11:44Так вот в ESS практически всё то же самое — редактор с подсветкой синтаксиса и автодополнением, выполнение произвольных комманд, в т.ч. и для показа графиков (в отдельном окне, правда, но, я думаю, это можно пережить :)), даже дебаггер вроде как есть (хотя я сам им не пользовался, так что про качество ничего не скажу). Так что тоже вполне себе IDE!
monah_tuk
21.08.2015 08:00+1Например, низкоуровневая разработка для linux.
Не про Linux, но под контроллеры, в т.ч. Baremetal, использую Qt Creator. Проект около 40k чистых строк кода на C++. Да и вообще использую для всякой мелочи, удобно. Программки на пробу пишу где душа ляжет: mcedit, gedit, а то и просто на ideone :-)
dunmaksim
21.08.2015 09:01+1Немного в защиту EMACS:
— не надо запоминать все эти комбинации, когда есть пакет ergoemacs-mode (рекомендую ставить из MELPA STABLE, в MELPA версия с глюками), который даёт старые добрые Ctrl+C, Ctrl+V и т.д.
— для запоминания клавиш можно распечатать небольшой лист формата A3 и повесить на стену, как я и сделал. Уверен, тем, кто работает в IDE, тоже может пригодиться такая штука.
— переход к определению методов, функций и классов можно сделать быстрым по Ctrl+. когда установлены нужные плагины. Для Python использую anaconda-mode, всем доволен. Есть такая же штука для JS — tern-mode, js2-mode.
— подсказки можно сделать с помощью company-mode (COMPlete ANYthere). Безусловно, развёрнутую документацию как в IDE в подсказке не всегда можно получить, но скажите, Вы правда пользуетесь встроенной справкой а не гуглом?n0dwis
21.08.2015 09:32О, а ergoemacs так можно устанавливать? Спасибо, не знал.
С официальным сайтом ergo у меня как-то не очень сложилось, хотя пару кусков из конфига себе забрал.
ffriend
21.08.2015 10:14— не надо запоминать все эти комбинации, когда есть пакет ergoemacs-mode (рекомендую ставить из MELPA STABLE, в MELPA версия с глюками), который даёт старые добрые Ctrl+C, Ctrl+V и т.д.
Можно даже проще:
(cua-mode)
Вроде во всех современных Emacs-ах он встроенный, надо только добавить в .init.el
alkresin
21.08.2015 09:46-3И если размер проекта приближается к 100 тыс строк и состоит из тысяч файлов...
Я не первый десяток лет профессионально занимаюсь программированием, сделал немало, но до сих пор не могу себе представить проект из нескольких тысяч файлов. Судя по комментариям на разных ветках, разных форумах такое встречается чуть не на каждом шагу, но я все равно не могу себе это представить, Какой должна быть задача, какой объем функций, чтобы потребовался такой монстр? И почему нельзя разбить его на связанные, но независимые субпроекты, каждый из которых вести отдельно?n0dwis
21.08.2015 10:35+3Текущий проект, на котором я работаю, состоит из 1368 файлов PHP и 109315 строк (непустых, без комментариев). Плюс библиотек (не стандартных) — 1962 файлов и 59843 строк. Плюс к этому всякие xml, css, html, js и т.п.
Предыдущий — тех же объемов. Порядка 1500 файлов и 98000 строк, а библиотеки даже не считал.
Оба проекта B2B, разные корпоративные функции со всеми вытекающими — пользователи, отчёты, админки с разными справочниками и т.п. Плюс много взаимодействий со внешними сервисами через soap, rest и всякие самописные протоколы.
Разбить код на несколько — можно, наверное. Библиотеки и разбиты. Но работает это всё равно всё вместе. И дорабатывать/исправлять надо вместе. Разделить вообще на несколько проектов для пользователей — не вариант.alkresin
21.08.2015 11:42Хм… Может, это специфика web-проектов. Ничего крупного в этой области я не делал — так, всякие мелочи, чтобы попробовать на зуб — поэтому не возьму на себя смелости давать оценки в этой области.
Самый крупный проект, с которым я имел дело — разработка компилятора с реально большой run-time библиотекой и набором утилит( скорее это можно назвать средой программирования ) ~640 файлов исходников ( c и prg ), из них ~230 — языковые ( сообщения на разных языках и кодовые страницы ). Здесь использование IDE исключалось уже потому, что этот продукт строится на разных ОС и поддерживает несколько разных С компиляторов.
Или, например, бухгалтерский и управленческий учет среднего ( ~1000 человек ) предприятия — ~180 файлов, но этот проект разбит на десяток субпроектов, связанных между собой, но разрабатываемых и компилируемых отдельно.
mukizu
21.08.2015 12:02+1>Здесь использование IDE исключалось уже потому, что этот продукт строится на разных ОС и поддерживает несколько разных С компиляторов
И таки почему исключается IDE?alkresin
21.08.2015 12:11-3А какое IDE вы предлагаете использовать, чтобы строить с его помощью проект на Windows, разных Unix, Linux, MacOs, Os/2, Android и чтобы поддерживались gcc, Borland C, Mingw, mvc, Watcom, Pelles C и пр.? К тому же ~110 файлов из упомянутых ~640 — prg и компилятор для них — тот самый, который строится.
BelBES
21.08.2015 13:22+3QtCreator в связке с cmake'ом… не?
monah_tuk
24.08.2015 04:10Но мне, для удобства, пришлось допилить CMake плагин. PPA: launchpad.net/~adrozdoff/+archive/ubuntu/qtcreator-git Ща используется CMake для baremetal с кросс-компилятором.
mukizu
21.08.2015 19:46Ну, ось проблемой как мне кажется точно быть не может, сейчас все IDE позволяют работать над проектами под любую платформу. OS/2 может быть какой-то проблемой (ни разу с ней дела не имел — не знаю), но вот все остальные проблемой быть не должны.
С компилятором честно говоря тоже не понял — в той же Идее можно указать каким компилятором пользоваться и вообще сделать n настроек запуска/сборки под каждый компилятор и/или его отдельную версию.
Либо я не до конца понимаю задумку.
bigfatbrowncat
22.08.2015 03:38Eclipse + GCC + Make. Под Windows это всё тоже есть. Вот как я себе окружение настраиваю: bigfatbrowncat.github.io/cross-building
ffriend
21.08.2015 12:15А расскажите, что именно из себя представляют эти проекты? Это обычный веб (грубо говоря, сайты) или что-то более хитрое?
Проект на Scala, над которым мы работаем последние месяца 4, содержит всего 360 файлов и 17729 строк. Spark Core — проект, мягко говоря, не маленький — 759 файлов и 90906 строк. Самый известный в Java менеджер зависимостей — Maven — имеет 1553 файла (из которых 413 — XML) и 101942 строк. Правда, если посмотреть, например, на CPython, то там мы видим 2736 файлов и 964228 строк, но так и проекту уже скоро четверть века.
Поэтому информация о сути ваших проектов и их длительности была бы очень полезна.ffriend
21.08.2015 12:55Продолжая список интересных фактов: старичёк GNU Emacs имеет в себе 2324 файло и 1455440 строк :)
n0dwis
21.08.2015 13:25Деталей разглашать не могу, извините.
Оба на php + фреймворк. В одном случае Symfony, в другом — самописные.
По сути оба — да сайты. Суть простая — создание и управление заказами. Но заказы состоят из мнножества различных сущностей, для которых нужны редактируемые справочники. Плюс всё это обрастает кучей бизнес-правил для разграничения доступа пользователей, для расчёта различных наценок/комиссий/курсов, для формирования отчётов. Нужны гибкие политики для обслуживания всего этого дела, и опять же админка. Множество усилий тратится на валидацию пользовательского ввода.
Например, чем недавно занимался — компании может предоставляться скидка в зависимости от некоторых условий. Скидка разная. Нужно уже 2 сущности doctrine — для хранения скидок и условий (можно и в 1-й но будет дублирование). Сами сущности (200 строк) + админки для них на sonata (154 строки). Это без комментариев и пробелов, хотя это не совсем корректно — в symfony аннотации играют большую роль. Но пусть так. Дальше — простенький сервис для их получения — 50 строк. Расчётчик + пара интерфейсов для работы с несколькими поставщиками — 68 строк. Использование всего этого — ещё около 20 строк. Это пока ещё бекенд. На фронте ещё порядка 10 строк на php, и куски на html и js.
Итого на не очень сложную фичу — 500 строк. Сущностей порядка 300. Даже только ими, без логики, проект вырастает до 50-60 тыс строк только на php.
Как-то так.
Flammar
21.08.2015 16:09Проект на Scala, над которым мы работаем последние месяца 4, содержит всего 360 файлов и 17729 строк.
Подозреваю, что на Java это проект занимал бы раз в 5 больше…
bigfatbrowncat
22.08.2015 03:37Откройте для себя Spring Framework, например: projects.spring.io/spring-framework
А я, к примеру, участвовал в разработке проекта, который на Spring-е был написан и сам по себе был не меньше.
Или, скажем, скачайте исходник самой IntelliJ Idea. И поглядите внутрь. Там поскромнее, но тоже увесисто классов.
Хотите другого, блолее низкого уровня — вытащите Android. Там тоже кода ой, как прилично.
Отдельно? Можно. Так и делают обычно. Но собирается всё вместе и по коду прыгать/разбираться приходится «насквозь». Помню, как я мучился, будучи неспособным весь libcore и Android Framework загрузить в Eclipse одновременно — памяти было всего 1,5 гига — комп старый… И вспоминать не хочется.
OnYourLips
21.08.2015 10:04-3В защиту IDE.
Когда говорят о ненужных функциях, обычно не могут их перечислить.
В той IDE, которую я использую, я использовал в различных проектах 95% всех возможностей, и понимаю, в каких ситуациях могут быть полезны остальные 5%.
Поэтому когда человек говорит о ненужных функциях в IDE, то скорее всего он просто не понимает, что они делают, для чего они. И через несколько лет он изменит свое мнение, когда придет опыт.n0dwis
21.08.2015 10:38Вот тут, уже, скорее, вопрос предпочтений.
Скажем, мне с БД удобнее работать через отдельное приложение, а не встроенный клиент в IDE. С git-ом та же история, хотя коммитеть удобнее, всё-таки из ide.
roman_kashitsyn
21.08.2015 10:49+2Текстовые редакторы объективно чуть лучше подходят для нестандартных задач и сред.
Например, у меня на работе разработка ведётся на удалённом linux-сервере специфической конфигурации без графической среды. Язык — C++. Некоторые коллеги используют NetBeans, т.к. в нём достаточно просто настраивается удалённый билд. При этом навигация по коду работает для объектов в рамках подпроекта, по системным хедерам он в такой конфигурации из коробки прыгать не умеет. Т.е. может и умеет, но мало кто осилил это настроить.
Многие поднимают sshfs и редактируют файлы любимым редактором (ибо от IDE уже толку немного — на локалке нет нужных хедеров, особенно если локалка — MacBook), а собирают проект удалённо из консоли.
Я захожу на сервер по ssh, у меня там месяцами живёт сессия tmux + инстанс emacs. При этом довольно забавно смотреть, как у коллег в их C++-IDE поддержка того же Python нулевая (в некоторых подпроектах есть биндинги к Python), плагина в репозитории, увы, нет. Emacs всеяден, довольно сносно поддерживает множество языков.
Возможность написания плагинов не такая эфемерная, как многим кажется.
У нас, к примеру, нестандартная вики-разметка. Вот так вот сложилось. Потребовалось совсем немного времени, чтобы запилить конвертер org-mode в разметку, а потом написать major-mode для редактирования разметки.
Ещё есть специальный shell, который выполняет команды на группах хостов в кластере. Несколько часов с доками поcomint— и я могу выполнять команды прямо из любимого редактора с гораздо большим удобством, чем работая из терминала. Более того, легко делиться наработками с коллегами — им нужно лишь вставить код в буфер и выполнить одну команду. Для автоматических обновления приватных плагинов нужно, конечно, настраивать свой плагин-сервер.
Emacs — отличная IDE. Для разработки на Emacs Lisp :) Переходы к определению функции, автодополнение, просмотр документации — всё это отлично работает, пока вы пишите на lisp. С другими языками, как правило, придётся потрудиться. Однако, есть несколько невероятно крутых и удобных языковых плагинов для Emacs, и заметна тенденция увеличения их числа:
- Весьма впечатлил tuareg-mode для работы с OCaml. Хотел бы я, чтобы C++ было редактировать так же удобно...
- Я не программирую на Elixir, но Alchemist впечатляет.
- idris-mode тоже выглядит весьма развитым
Вообще говоря, заметно общее увеличение активности Emacs-сообщества. Надеюсь, нас ждёт ещё много отличных плагинов, и когда-нибудь разработка на C++/Java в Emacs будет действительно приятной.BelBES
21.08.2015 13:37Я захожу на сервер по ssh, у меня там месяцами живёт сессия tmux + инстанс emacs
Хм, в emacs есть tramp-mode, через который можно на удаленные машины по томуже ssh ходить аки тонкий клиент… в чем смысл запускать emacs на удаленной машине?
Вообще говоря, заметно общее увеличение активности Emacs-сообщества. Надеюсь, нас ждёт ещё много отличных плагинов, и когда-нибудь разработка на C++/Java в Emacs будет действительно приятной.
Для начала неплохо бы добавить полноценную многопоточнсть в emacs… без неё ни о каких полноценных intellisense говорить не приходится)ffriend
21.08.2015 14:09Могу сказать за себя: всё зависит от последовательности действий — обычно я просто лезу на удалённый сервер, изучаю содержимое файловой системы, запускаю какие-то команды, и только когда нужно отредактировать какой-то файл, не переключаясь из окна SSH, открываю файл удалённым Emacs-ом прямо на сервере и делаю нужные правки. А потом продолжаю работать в консоли, и так по кругу.
BelBES
21.08.2015 14:19Ну да, tramp позволяет dired'ом ходить по удаленной ФС, выполнять команды на удаленном сервере и редактировать на нем файлы. Собственно он тупо подключается по ssh, а дальше работаешь как с локальной машиной.
roman_kashitsyn
21.08.2015 14:39Хм, в emacs есть tramp-mode, через который можно на удаленные машины по томуже ssh ходить аки тонкий клиент… в чем смысл запускать emacs на удаленной машине?
Я пробовал работать через tramp-mode, но для полноценной разработки он мне не очень понравился.
Во-первых, есть определённая задержка в отклике, больше, чем у терминала.
Во-вторых, у меня как-то не очень получилось подружить clang-format с tramp-mode.
В-третьих, tmux на удалённой машине позволяет держать инстанс Emacs открытым очень долго, переживать рестарты и выключения локальной машины. Сервер выключается гораздо реже, чем дев-машина.BelBES
21.08.2015 14:57Ну, впринципе если есть возможность свой конфиг утащить на удаленную машину, то может быть консольный emacs и вариант.
Лично у меня с tramp проблем никаких не возникало.roman_kashitsyn
21.08.2015 15:09если есть возможность свой конфиг утащить на удаленную машину
У меня все конфиги на GitHub, устанавливаются на любую машину в одинmake install. Пути к программам и прочая мелочь донастраивается через M-x customize в отдельный файл (попадающий в.gitignore) по мере необходимости.BelBES
21.08.2015 15:24Ну, у меня бывала нужда ходить на железку, у которой не было доступа в интернет, т.ч. варианты с выкачиванием из чего-то из большой сети отпадали. Tramp тогда сильно выручал.
з.ы. а может поделитесь ссылкой на свой конфиг? Похоже, что вы тоже разрабатываете под C/C++, может чего интересного у вас там есть под эти языки)roman_kashitsyn
21.08.2015 15:29может чего интересного у вас там есть под эти языки
Да не то чтобы прям что-то интересное было, допил минимален. Пытаюсь больше стандартными средствами обходиться. Мне важен indentation и M-x compile, всё остальное делают плагины и сторонние утилиты.
github.com/roman-kashitsyn/dot-files/tree/master/.emacs.d
PerlPower
21.08.2015 14:51tramp-mode не даст работы с хедерами, к тому же он медленный. Поправить страничку на сайте он еще годится, а вот если проект из кучи связанных файлов и по ним нужна навигация, то лучше сразу пускать emacs на удаленном сервере.
roman_kashitsyn
21.08.2015 14:55Для начала неплохо бы добавить полноценную многопоточнсть в emacs… без неё ни о каких полноценных intellisense говорить не приходится)
Эта проблема давно решается запуском многопоточного бэкэнд-процесса, асинхронно выполняющего все медленные операции. Можно воспринимать Emacs как GUI-thread, все операции с буферами и текстом должны выполняться в одном потоке. Хочется асинхронных воркеров — поднимай подпроцессы, настраивай message-passing.
В Vim, например, даже c этим есть проблемы — нельзя породить подпроцесс и асинхронно с ним общаться. Так что в Emacs ещё всё относительно неплохо.BelBES
21.08.2015 15:00Эта проблема давно решается запуском многопоточного бэкэнд-процесса, асинхронно выполняющего все медленные операции.
И несмотря на это, в emacs до сих пор простейшие операции, типа комментирвоания пары сотен строк кода, подвешивают редактор)roman_kashitsyn
21.08.2015 15:16простейшие операции, типа комментирвоания пары сотен строк кода, подвешивают редактор
Честно говоря, это странно, уж слишком смешные объёмы текста. Возможно, font-lock правила были криво написаны и медленно перекрашивали буфер. Или был включен Semantic — он обычно сильно тормозит, я его отключаю.
Да и врядли тут многопоточность сильно поможет — редактировать буфер в UI всё равно должен один поток. Помочь скорее может более оптимальная виртуальная машина. Возможно, когда нибудь Emacs переведут на Guile vm, должен быть неплохой буст производительности.
Я как-то курочил SQL-файл на пару десятков тысяч строк макросами, особых тормозов не замечал.BelBES
21.08.2015 15:20Ну, быть может строк было чутка побольше, чем пара сотен, но факт, что ST с этой задачей справлялся без запинок. Semantic я даже не включаю, т.к. он впринципе какой-то глючный, или я не умею его готовить.
А по файлам >500mb даже тупо навигация еле еле шевелится(roman_kashitsyn
21.08.2015 15:41факт, что ST с этой задачей справлялся без запинок
Так у ST всё ядро на C++ написано, а в емаксе почти всё, что за гранью примитивных операций (в т.ч. то, что относится к работе с комментариями и подстветкой) — интерпретируемый лисп и регулярки. Повторюсь, многопоточность тут почти наверняка не выход, нужно ускорять ядро.
IvanAnonym
21.08.2015 11:17+5Эту статью, например, я пишу в Emacs.
Вы уж простите, но лучше бы писали в более простом текстовом редакторе, но с проверкой орфографии. Хорошая статья, но всё впечатление портят многочисленные ошибки.
Пользуйтесь своим же главным посылом: инструмент должен соответствовать задаче.
ZoRgSoft
21.08.2015 13:04Сам недавно испытывал подобные муки выбора, перебрал множество разных редакторов и IDE, в итоге, остановил свой выбор на Sublime Text 3 (немало пришлось повозиться и настраивать) и Netbeans для разработки на PHP, а для работы с JavaScript когда то купил WebStorm.
Хотел бы купить PhpStorm но для меня это пока дороговато.
Также ранее вместо Sublime Text использовал (в WIndows) Notepad++, хотя и сейчас его тоже иногда использую когда надо быстро поправить одиночные файлы с кодом.
P.S. Т.к. я часто работаю и в Linux, то в нём, я обычно для разработки использую gedit и Netbeans.
dmitryanufriev
21.08.2015 13:31+2Мне кажется, что в рассуждениях IDE vs текстовый редактор есть доля лукавства. Я практически не встречал людей, которые в профессиональной разработке пользуются только текстовым редактором. Все случаи использования Vim и Emacs в повседневной работе заключаются в том, чтобы взять эти инструменты и превратить их в IDE.
Например, мне для более менее комфортной работы (Emacs) требуется 23 плагина:
(depends-on «nlinum»)
(depends-on «which-key»)
(depends-on «powerline»)
(depends-on «projectile»)
(depends-on «auto-complete»)
(depends-on «highlight-symbol»)
(depends-on «magit»)
(depends-on «yasnippet»)
(depends-on «helm»)
(depends-on «helm-projectile»)
(depends-on «helm-ag»)
(depends-on «virtualenvwrapper»)
(depends-on «anaconda-mode»)
(depends-on «ac-anaconda»)
(depends-on «flycheck»)
(depends-on «web-mode»)
(depends-on «emmet-mode»)
(depends-on «json-mode»)
(depends-on «js2-mode»)
(depends-on «ac-js2»)
(depends-on «coffee-mode»)
(depends-on «tern»)
(depends-on «tern-auto-complete»)
Так что, наверное, можно признать, что подавляющему большинству программистов нужна именно IDE (с теми или иными возможностями). Разница заключается в том, что из Vim или Emacs IDE нужно делать самому. А здесь основная мотивация — это очень интересно! И как бонус, в случае ошибок почти всегда есть возможность посмотреть, что происходит внутри и связаться с авторами того или иного плагина (например, автор Tern отвечает достаточно оперативно).
В общем, если вы в детстве ломали игрушки, чтобы посмотреть, что у них внутри, то, скорее всего, вы уже используете Vim или Emacs :)
Кстати, мое мнение — Emacs ну никак не текстовый редактор, это скорее виртуальная машина с языком Emacs Lisp на борту.n0dwis
21.08.2015 13:41Объясните, пожалуйста, что такое helm? Я внятного описания не могу найти.
dmitryanufriev
21.08.2015 13:54В моем понимании это штука для быстрого поиска «всего и вся» (условно). Как фильтр из множества доступных вариантов (например, при поиске файла, функции Elisp, буфера и т.д.). Раньше называлась anything. Здесь кратко описывается как “uber-extensible spotlight for emacs” или “QuickSilver for emacs”. Имеет интеграцию со сторонними плагинами — silversearcher, projectile и еще много с чем. На MELPA можно посмотреть в результатах поиска по строке «helm».
webkumo
21.08.2015 17:06-1Видимо я в детстве сломал слишком много игрушек — не тянет меня к конструкторам. А по плагинам — часть плагинов той же IDEA вполне можно поисследовать (те, которые входят в бесплатную версию), те что не входят — по ним всегда можно тикеток отправить разработчикам…
powerman
21.08.2015 20:05+3И здесь ему редактор не может помочь абсолютно ничем.
Это неправда. Всё сильно зависит от языка программирования и установленных плагинов. Например, для яыка Go и плагина vim-go:
Список параметров метода во всплывающей подсказке не покажет,
Покажет. Либо вызываем:GoInfoкогда курсор на нужном слове, либо включаем в настройкахlet g:go_auto_type_info = 1и подсказка выводится постоянно по мере перемещения курсора.перейти к определению метода не позволит,
Позволит. Штатная команда Vim:gd(goto definition).синтаксис не проконтролирует.
Проконтролирует. При каждой записи файла выполняется проверка синтаксиса, выводится список найденных ошибок и курсор прыгает на первую ошибку.
GooRoo
21.08.2015 20:21А где подсказка-то со списком параметров метода?
powerman
21.08.2015 20:38Внизу.
GooRoo
21.08.2015 20:45-5Она находится вне локуса внимания, то есть интерфейс не человеко-ориентированный.
powerman
21.08.2015 20:48+1А, ну тогда да, конечно, только IDE! Раз вне локуса…
bigfatbrowncat
22.08.2015 03:50-1Простым языком звучит так: дергать глаза всё время в низ экрана (а экран может быть 25 дюймов, например), а потом обратно — глазные мышцы сведет.
Delphinum
22.08.2015 11:23То есть дергать руки с клавы мышь или изгибать пальцы веером для сочетаний вида Ctrl+Alt+Up это как бы норм, а глазные мышцы, эт слишком, да?
bigfatbrowncat
23.08.2015 09:39Я использую сочетания клавиш тогда и только тогда, когда это приводит к заметному росту производительности. Вот, недавно, например, сидел в отладчике долго и запомнил, что там F6 — step over, а F7 — step in. Или наоборот… забыл уже, в следующий раз погляжу.
А автодополнение вызывается «Ctrl+Space» и используется процентов 60 времени, которое я пишу код. И если я буду зенками вращать вверх-вниз по пять раз за набор строчки, у меня морская болезнь начнется.Delphinum
23.08.2015 11:48Я использую сочетания клавиш тогда и только тогда, когда это приводит к заметному росту производительности
Не знаю таких сочетаний клавишь, который приводили прямо таки к заметному росту производительности. Все они немного увеличивают скорость, но если их много, то и производительность возрастает заметно.
И если я буду зенками вращать вверх-вниз по пять раз за набор строчки, у меня морская болезнь начнется
Вращать не нужно, у вас же монитор не метровый ))bigfatbrowncat
23.08.2015 13:11-2Не знаю таких сочетаний клавишь, который приводили прямо таки к заметному росту производительности
А попробуйте вместо хоткея для открытия подсказки в IDE использовать кнопку на панели. Да-да, там такая есть :)Delphinum
23.08.2015 13:38+1А разве взяться за мышь, навести на кнопку на панели и нажать ее проще, чем нажать одну-две клавиши?
bigfatbrowncat
24.08.2015 17:30Так нет же! Я же вам и доказывал, что наличие этого хоккея приводит к заметному росту производительности. Вы сказали «не знаю», а я привел пример. Теперь вот знаете.
GooRoo
22.08.2015 02:00Мдэ. Раскина по ходу народ не читал. Окей, чо.
Delphinum
22.08.2015 11:24-1Я могу ошибаться, но мне кажется, что для того, чтобы понять удобный ли это инструмент или нет, не нужно читать книг.
GooRoo
22.08.2015 12:09-1Согласен. Мне вот даже этим инструментом и пользоваться не пришлось, чтобы понять.
bigfatbrowncat
23.08.2015 09:42Ну… это — выбор каждого. Кто-то книги читает, а кто-то испытывает на себе. Я вот в детстве почитал немного про то, как наркотики влияют на организм, оценил все плюсы и минусы и с тех пор искренне не понимаю фразу «хотелось попробовать», которой объясняют начало наркотической зависимости многие люди. Хотя это уже оффтоп. Простите.
Delphinum
23.08.2015 11:49Этот оффтоп уже из области философии. Практика она все таки имеет больший приоритет, нежели теория.
bigfatbrowncat
23.08.2015 13:13Проблема в том, что большинство людей, увы, за всю жизнь не догадаются до кучи полезных вещей, которые не очевидны, пока в них человека носом не ткнуть. И эргономика — как раз из их числа. Так что ваша личная практика мало стоит по сравнению с теорией, основанной на научном исследовании общечеловеческой психологии. В ней тоже есть научные закономерности, поверьте.
Delphinum
23.08.2015 13:42Возможно, но моя личная практика говорит, что в отделе я пишу прогу раза в два быстрее на Vim, нежели мои коллеги на Mac тачпад + PHPStorm. Как это объясняется исследованиями?
bigfatbrowncat
24.08.2015 17:31+1Изучите в совершенстве PHPStorm. И сравните себя с собой же. И честно ответьте себе на свой вопрос. Только тогда ваш ответ будет хоть немного объективным… Для вас же.
powerman
21.08.2015 20:41На предыдущем скриншоте, кстати, пример всплывающей подсказки при автодополнении. Там показаны переменные (Stdin, etc.), но при автодополнении имён функций там же показываются не только имена, но и полностью сигнатуры этих функций.
powerman
21.08.2015 20:46Вот результат набора
fmt.P<Tab>
bigfatbrowncat
23.08.2015 09:43-1Это уже получше смотрится. Теперь оно немного похоже на текстовый Eclipse :)
Выглядит действительно стильно, черт побери! Если еще будет много текста убираться, да окошки добавить с ошибками, отладчиком… В общем, есть, куда развивать, есть. Надеюсь, это всё кто-нибудь напишет, а то у меня времени не хватит :)
fogone
22.08.2015 02:13+2я тоже пользуюсь редактором, называется idea, хороший редактор, очень много всего умеет, удобный. Честно сказать, не совсем понимаю как разделить редактор и ide, критериев нет. ide это новый виток развития «редактора» для разработки. Так что вим+плагины тоже ide. А уж каким инструментом пользоваться — каждый выбирает сам, на то и есть разнообразие.
bigfatbrowncat
22.08.2015 03:53Слово «редактор» для людей, его использующих, обычно обозначает «одна штука на все случаи жизни». Вот вы этот комментарий к статье в Idea писали? Нет? Значит она — не редактор, а «вшивая IDE», ни а что не пригодная, кроме этой вашей корявой Джавы.
(на всякий случай, я сам — Java-разработчик, а всё написанное выше — сарказм)
asm0dey
22.08.2015 09:36-1За шесть лет коммерческой разработки не осталось, наверное, ни одной функции, которой я не воспользовался бы в любимой JetBrains IDEA. Поэтому не согласен насчёт ненужного. Насчёт монструозности и тяжести частично согласен, поэтому для совсем небольших проектов использую vim/sublime… До тех пор, пока не понадобится рефакторинг. Ни один режактор не умеет рефакторинг Java так, как его умеют IDE. И не сумеет никогда.
Delphinum
22.08.2015 11:25И не сумеет никогда
С чего вы так решили?asm0dey
22.08.2015 13:07Потому что для, чтобы, например, вынести метод в абстрактный класс-родитель редактор должен понимать, что вообще такое абстрактные классы. А для этого он должен быть частью IDE, а не редактором.
Delphinum
22.08.2015 21:45Эмм, нет, для этого достаточно прикрутить к редактору синтаксический анализатор.
asm0dey
23.08.2015 09:23А что, с вашей точки зрения, отличает редактор от IDE?
DrLivesey
23.08.2015 11:29+2Из расшифровки IDE — Integrated Development Environment, я осмелюсь предположить, что разница заключается в том что в IDE все необходимые для разработки инструменты (редактор, синтаксический анализатор, компилятор и отладчик) собраны и положены в коробку.
В случае с редактором все это нужно собрать и положить самому, однако как только все сложено вместе редактор становится IDE следуя той же самой расшифровке.
Вывод: IDE — сумма компонент, а редактор неотъемлемая компонента IDE.asm0dey
23.08.2015 12:28Правильно. Вот поэтому редактор перейдёт из состояния редактора в состояние IDE. Называть редактором штуку с синтаксическим анализатором и так далее — некорректно. Это как микроскоп лупой называть. Формально, может, и правильно, а фактически — уже нет.
Delphinum
23.08.2015 11:50Множество дополнительных плагинов, которые нужны для разработки на данном ЯП.
BelBES
23.08.2015 10:56К emacs уже давно привнитили, например, синтаксический анализатор от clang для работы с C++ (не суть что криво и не всегда работае, важен факт), т.е. теперь emacs — это IDE для C++?
Delphinum
23.08.2015 11:52Ну как таковой, явной границы между редактором и IDE нет. Я не пользователь emacs, но если он умеет понимать синтаксис C++, то считаю что да, он есть IDE для C++. Не важно, есть ли в нем дебагер, рефакторинг, автозавершение, это уже, на мой взгляд, плюшки, главное что он понимает, что это не набор слов, а текст программы.
RoSenMann
11.09.2015 07:48Причем, дебагер, автозавершение и прочие вещи в emacs вполне себе прикручиваются. Так что не знаю как насчет шутки про «ОС с плохим текстовым редактором», но серьезное утверждение про IDE так-то справедливо.
RoSenMann
11.09.2015 08:13А так-то, к сути. Есть такой момент не только среди emacs'ров, но и любых продвинутых пользователей — когда ты достаточно долго чем-то пользуешься — начинаешь строгать напильником свой инструмент доводя его до максимального КПД, я видел несколько людей, чья работа связана с офисными пакетами (написать, посчитать и п.р.), которые спустя полгода уже вовсю строчили на VB, допиливая формы. Мой товарищ, который занимается изданием нотных сборников насобирал за полгода целую кучу активно юзаемых макросов во Frescobaldi и Notepad++. Я emacs'ом начал пользоваться несколько месяцев назад «как он есть», сейчас же, имея там noweb-mode и еще пару полисинтаксических режимов — я не хочу с него слезать. Потому что к хорошему быстро привыкаешь (ну и как бы IDE не умеют полисинтаксис). А команды перестают выламывать пальцы, когда понимаешь, что как бы setxkbmap -option 'ctrl:nocaps'. К слову, дефолтные хоткеи емакса работают и в nano и в терминале, если речь о linux. Вот как бы и все. Что-то является неудобным, только если это нельзя доступно настроить.
roman_kashitsyn
11.09.2015 08:58> noweb
Вы реально что-то пишете в literate-стиле? Я так понимаю, это исключительно для себя?RoSenMann
11.09.2015 15:36Не знаю, насколько я по Кнуту пишу, но стараюсь писать все. Я программированием не зарабатываю, и по учебе часто приходится делать какие-то расчеты и вести отчетность, т.о. я двух зайцев одновременно убиваю, и правки без геморроя сразу идут в конечный документ, да и преподавателю такой код просмотреть намного интересней
roman_kashitsyn
11.09.2015 15:55Раз уж вы пользуетесь Emacs, посмотрите ещё Babel. Он во многих отношениях занятнее, чем noweb. Можно перемешивать код на разных языках, передавать результат работы одного куска кода на вход другому, даже выполнять код на удалённой машине (через tramp).
Monnoroch
Необходимость, ага. У меня половина коллег кодит в виме. Многие в саблайме. Некоторые виндусятники в нотпаде++.
В IDE — меньшинство знакомых (почти только джависты). Вот такая вот необходимость.
KumoKairo
А на чём кодите (Вы и коллеги/знакомые), если не секрет?
Monnoroch
C/С++, python, Go, js — масштабно, ну и так, балуюсь на всем по мелочи.
Я себе для веба даже поделку под ST сделал: packagecontrol.io/packages/Color%20Highlighter.
DenimTornado
Ну я понимаю компилируемые языки, но тот же js...Webstorm ведь шикарен для разработки, и поделки не нужны, всё в коробке.
Holms
WebStorm не подерживает синтаксис для JSX (ReactJS) файлов, пришлось переходить на Atom.
DenimTornado
уже поддерживает http://blog.jetbrains.com/webstorm/2014/10/webstorm-9-released-meteor-support-react-and-jsx-gulp-integration-and-more/
js605451
По-моему ни для одного из этих языков нет IDE, в которой бы сносно работал рефакторинг (более сложный, чем rename). А без рефакторингов IDE это действительно просто текстовый редактор с подстветкой, обвешанный парой плагинов. Отсюда и мнение что IDE не нужно.
tangro
Отвечу за С++:
Вещи типа автоматического включения инклюдов, выноса кода в метод, переименования сущностей, реализация стабов методов интерфейса, навигация по коду, подсветки, подсказок, автодополнения — работают очень хорошо.
dimcha
А Вы код ядра пробовали в CLion открыть и что-нибудь попытаться написать новое? И завязка на CMake имхо сильно сковывает, когда куча проектов на обычном gnu make.
BelBES
Хм, а в чем конкретно вас сковывает cmake?
dimcha
Тем, что надо прописывать ВСЕ исходники со всеми подключаемыми либами. Все как в make, но вот ни о каком автодополнении и прочих сладостях CLion и думать не приходится, пока все это не опишешь в конфиге. И по маске добавить нельзя. Вот честно, искал решение и не нашел, все уверяют, что надо четко каждый файл прописывать. А на больших проектах, где 100500 файлов, типа squid, для того чтобы чтото поправить, надо с нуля сборку написать. Ну это разве нормально?!
BelBES
Честно говоря не понял о чем вы… писать cmake-скрипты и проще и быстрее, чем обычные make'и… а вот то, что в CLion оно работает как-то не так… ну это проблема этой IDE, а не cmake'а.
roman_kashitsyn
О том, что нужно переписывать всю систему сборки только ради того, чтобы воспользоваться IDE. У нас, например, свой build-framework, основанный на make, который во многом удобнее изкоробочного cmake. У некоторых коллег есть лицензия CLion, но они так и не смогли его эффективно использовать — код компилируется на удалённом сервере + система сборки — не cmake.
monah_tuk
Написать — проще. Портировать существующую сборку с нуля на XXX — бывает архисложно. А делать это, только, что бы открыть код в IDE вообще моветон. В QtC это элегантно решили.
BelBES
Почему архисложно? В большинстве случаев под платформу XXX уже есть cmake и можно собираться нативно на таргет-устройстве. А для кросскомпиляции достаточно написать правильный toolchain файл. При этом голые make'и под банальный Windows уже придется собирать либо под MinGW, либо переписывать все на nmake, что не очень интересно.
monah_tuk
Вы пытаетесь подменять понятия: в ответе на habrahabr.ru/post/265197/#comment_8545795 и на мой комментарий выше.
Объясняю: речь про CLion. Он может сейчас эффективно работать только с CMake проектами. Это и есть завязка — завязка CLion на CMake. Вы же начинаете про скованность самого cmake. Да никого он не сковывает, просто есть куча проектов которые его не используют. И работать с ними в CLion — сложно и неудобно.
Теперь про портирование. Ядро Linux не использует CMake для сборки. Попробуйте портировать с kbuild на CMake — это и есть портирование. Да, если проект использует уже CMake, то написать грамотный тулчейн и вуаля. Главное, что бы кривожопость некоторых авторов правил в CMakeLists.txt не приводила к мукам. А такие криворучки попадаются на удивление часто.
Вроде всё по полочкам разложил.
fareloz
Ничего себе поделка, топ100 значок имеет)))
Monnoroch
Это только потому, что там нет значка топ30!
А если серьезно, то не такое уж и достижение, там кода-то совсем ничего, и большая часть — обходы косяков апи ST.
Monnoroch
del.
Monnoroch
Вообще, я ни в коем случае не говорю, что ИДЕ — отстой, не пользуйтесь ИДЕ. Просто есть неопровержимые доказательства отсутствия необходимости и факта первостепенности именно нашего желания.
igordata
Не, ну если «обычный» текстовый редактор после довеса парочки плагинчиков делает то, что должна делать IDE, то волей-неволей грань стирается…
Flammar
bigfatbrowncat
С Java всё весьма просто объясняется :) Из-за указанной вами строгой типизации и кучи стандартов/договоренностей, принятых в языке, которые не только упрощают разработку, но и помогают избежать кучи ошибок, на Java пишутся программы такого масштаба и сложности, который часто и не снился большинству других языков. Привет из Java Enterprise, в котором миллион строк кода — небольшая программа. Причем я одно время такую рограмму разработал и целый год поддерживал в паре с еще одним разработчиком. Вдвоем за 3 месяца написали, вдвоем год улучшали. Почти ни на одном другом языке такое даже не снилось (вероятно, конкуренцию могут составить C#, ruby и, возможно, python, но про последний — сомневаюсь).
А в проектах такого размера без IDE с ее быстрым контекстным поиском, автодополнением, переходом от одного куска кода к другому в один клик и т. п. — не обойтись.
А для C++, кстати, весьма неплох eclipse. Особенно для гибридных проектов C/C++ + Java. Там вообще пока альтернатив нет. Он, конечно, Си понимает хуже, чем родную Java, которую даже компилирует сам, вообще без участия javac, но всё равно неплохо.
sayber
У нас в команде из 10 человек, все пользуются исключительно PHPStorm.
Те кто предпочитают vim, notepad — значит такие программисты или мазохисты, или времени бесконечно.
C IDE процесс разработки превращается в рай и время на разработку продукта сокращается во много раз.
Miklos
Или они достаточно квилифицированны. Vim даёт невероятный прирост скорости.
Чтобы изучить PHPStorm тоже надо время.
sayber
vim дает прирост скорости?
Уж по мне так sublime интереснее.
Ну и vim надо еще изучать, или хотя бы переписать все хоткеи как в популярных редакторах.
Какой бы программист не был, с IDE он все равно будет быстрее писать код, видеть все ошибки и т.д. Он будет погружен полностью в проект, чувствовать каждый кусочек. Тысячи файлов должны быть как единый организм, а не как куски не пойми чего.
Вы ведь должны понимать, что скорость и качество, это главное в нашей работе, если конечно вы работаете не на себя.
P.S.
Для работы с PHP использую исключительно IDE PHPStorm.
Для работы с Go — sublime
Miklos
Просто Вы не знаете vim, ничего переписывать там не надо, потому что в vim'е нет хоткеев в привычном понимании этого слова.
Кстати, я тоже использую PHPStorm, но с плагином IdeaVim.
sayber
Когда пользуюсь vim, всегда использую простые хоткеи, тот же shift+ZZ or shift+ZQ.
Значит есть хоткеи, просто они совершенно отличны от всего софта.
Miklos
Это не хоткеи. Это команды, которые могут складываться вкомбинации, как буквы складываются в слова.
Neuronix
Вот так всегда… Как только кто-то говорит, что IDE лучше чем vim/emacs, потому что — 1,2 и 3, контраргумент — «вы не знаете vim!»… Аргх
Xitsa
Потому что это пустой спор, в нём не нужны аргументы.
По мне, в IDE есть редактор текста и он проигрывает как редактор и VIM и Emacs.
Для себя я решил всё проще: я работаю в IDE, но когда надо что-то отредактировать, я нажимаю горячую клавишу и оказываюсь в VIM, выполняю то, что хотел, и снова оказываюсь в своей IDE.
Для меня это оказалось гораздо комфортней, чем отсутствие средств IDE в редакторе, или отсутствие нормального редактора в IDE.
Neuronix
Тема холиварная. IDE — это сумма компонентов для удобного управления проектом (а он может быть большим). Например, моё личное мнение, что если кто-то будет писать на Java в vim/emacs, то этот человек жутчайший извращенец.
Delphinum
Не нужно голословных заявлений ;)
bigfatbrowncat
Про PHP не скажу. Про Java скажу. Посмотрел бы я, как вы в Vim будете анализировать и разбираться в проекте классов так на 100-150. На одно только переключение и поиск имплементаций интерфейсов, например.
Использование Vim при наличии продвинутой IDE говорит либо о том, что вы — пожилой специалист с закостенелыми привычками, которому трудно изучить новый инструмент, либо, что вы — студент, который чувствует себя более уверенно, работая в текстовом редакторе, из которого сверстники даже выйти не могут без его помощи (понты же!), либо человек, который просто не стремится выжать из окружения максимум возможностей. Очевидно, что среда, заточенная под конкретный ЯП, будет и удобнее, и эффективнее. Но загвоздка в том, что ее надо настраивать, изучать (а современные IDE сложны), а это — лень. А без адекватной настройки она — да — будет скорее мешать, увы.
ffriend
Интересно, что большинство сторонников IDE здесь в комментариях придерживаются как раз мнения, что настраивать нужно «редактор».
bigfatbrowncat
Настройка настройке — рознь. Есть такая категория пользователей, которые готовы написать сто консольных команд и попроавить 50 строк в конфиг-файлах, но пассуют перед простым окошком «Properties». Просто так устроен их мозг, что GUI он не воспринимает. Я собственными глазами видел пару таких разработчиков. Они мучались и «жрали кактус», долго пытаясь превратить vim в недоделанный eclipse. И в итоге, когда я им показывал, что чтобы обновить список импортов во всем проекте, надо дважды кликнуть мышкой по менюшке, кривились: «как же так! серьезные программисты не пользуются мышью!»
На мой взгляд, основу такого отношения (в случае Java) закладывает снобизм. Человек не стремится решать задачу эффективно. Он стремится решать ее красиво. В смысле — красиво выглядеть в процессе решения. Это — психология, как я думаю. Рациональные доводы здесь ни при чем.
bigfatbrowncat
И еще — про «долгую настройку». Я тут уже в комментах где-то писал, что по моим критериям «долгая настройка» — это полчаса-час после установки IDE. При условии того, что проект сложный и реально нуждается в этой долгой настройке. А ответил я это человеку, который сказал, что он…
Вот этот комментарий: habrahabr.ru/post/265197/#comment_8545391
Просто несколько разные масштабы времени соответствуют в нашем сознании понятию «долгая настройка».
Miklos
Т.е. изучать и настраивать вим им не лень, а идешку они не осилят? Ну, возможно, мышкой будут по кнопкам промахиваться.
Вообще Ваш комментарий довольно оскорбителен и категоричен.
bigfatbrowncat
Прочтите мой предыдущий комментарий, пожалуйста. Краткий ответ: да, не осилят, потому что недостаточно мотивации. Не хотят они ее осиливать — она не соответствует их чувству прекрасного.
Вот я, к примеру, люблю Eclipse и не люблю Idea. С эстетической точки зрения. Рациональных аргументов в пользу того или другого почти нет — просто это две разных «культуры» разработки на Java. По функционалу они близки, поэтому я долгое время имел возможность выбирать ту, которая мне по душе и не чувствовать себя отстающим.
Но сейчас мне «по долгу службы» пришлось влезть внутрь IDE — делаем плагины для Android Studio — и тут уже, увы, приходится изучать Idea и пользоваться ею. Я мог бы до конца «стоять на своем» и упорно всё кодить в Eclipse, но я лучше буду знать обе среды в равной степени — тогда у меня будет больше аргументов при «холиварах» ;)
А если серьезно, то ничего оскорбительного, на самом деле, я сказать не хотел. В основном, как и везде, программисты — адекватные люди, которые выбирают инструмент к задаче. Но бывают, согласитесь, отдельные «упоротые» индивиды, которым не важно, что делать — лишь бы не учить эти мерзкие кнопочки-окошечки. Вот про эту категорию я и высказывался.
Miklos
Привычка. У меня сейчас похожая ситуация с Visual Studio, но там ReSharper есть, не так больно.
bigfatbrowncat
Привычка — злейший враг представителя профессии, в которой, если верить «отцам», необходимо изучать в год по одной совершенно новой, незнакомой технологии. И с ней следует бороться, так как она ограничивает творческий и трудовой потенциал.
Miklos
Поддерживаю. Периодически надо ломать себя, кругозор как-то шире становится.
Alexeyslav
Кругозор становится шире, но память не резиновая… новое постепенно вытесняет что-то так же необходимое. Не у всех достаточно большой объем памяти чтобы безболезненно постоянно изучать новое и не забывать насущное.