Джо Армстронг об инструментах разработчика

http://erlang.org/pipermail/erlang-questions/2014-January/076660.html
  • Перевод
Недавно на Erlang-mail листе проскочил следующий вопрос:
Тулы, которые у нас есть для разработки на Erlang — просто мусор! Я прошу прощения, но сейчас 2014-ый, а мы все еще используем Vim и Makefile'ы. Да, есть Rebar. Но по сравнению с Maven, Gradle (или даже SBT) это студенческая поделка, которую кто-то выложил на GitHub. Про плагины для Eclipse и Intellij я вообще молчу. Они просто не работают. Поэтому я всегда возвращаюсь к Vim. Я просто хочу писать код, который решает мою задачу а не думать о том как написать Makefile со всеми зависимостями.


Ответ Джо Армстронга, автора языка Erlang:

Тулы никогда не смогут заменить вам головы. Ничто, из того, что вы перечислили не помогает мне думать. В реальной жизни, бОльшая часть времени уходит именно на обдумывание задачи. Поэтому, как только у вас есть решение — вы сможете запрограммировать его в течении пары часов.

Лучший инструмент, который у нас есть это конечно математика или более точно, логические выводы и доказательства.

Есть два тип программистов. Одни пишут 10 строк в день и уверенно двигаются к конечному продукту. Другие — пишут 100 или даже 1000 строк в день но топчутся на месте. Они никода не получат продукт, потому-что не понимают какую задачу решают. Они пишут тонны кода, чтобы это понять. Это создает иллюзию занятости и неплохо оплачивается.

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

Я предпочитаю думать о том, как на самом деле работает мое приложение, а не о том, как работает Eclipse. Редактирование кода — это не проблема. Меня вполне устраивает Emacs или даже ручка с бумагой, которые, в отличее от Eclipse, всегда можно взять с собой.

Я трачу 65% времени на то, чтобы разобраться почему не работает тот или иной тул. Каждый раз, появляются какие-то проблемы и мне постоянно приходится их исправлять. Тулы абсолютно бесполезны, когда они сломаны.

Проблема не в самих тулах, а в том, что когда они сломаны, все время уходит на то чтобы их починить. Поэтому я стараюсь использовать только самый минимальный и простой набор. Emacs, make и bash — все что мне нужно.

Я помню времена, когда программисты отлично понимали друг друга. Каждый, кто умел программировать — знал как написать Makefile и bash скрипт. Сейчас же, человек который ничего не видел кроме Java и Maven входит в ступор, когда ему присылают Rake-файл.
Поделиться публикацией

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

    +1
    Make-файлы действительно ужасны. Код на бейсике и тот лучше выглядит:)
    Я вообще за декларативный подход к описаню проектов вместо императивного, т.е. это должен быть не скрипт типа make-файла, а иерархический файл на базе xml или чего-то подобного, внутри которого в определенных узлах дерева содержатся имена файлов проекта, зависимости, опции компиляции и т.п. Более того, я склоняюсь к мысли, что базовый формат файла проекта должен включаться в стандарт языка программирования, чтобы любой компилятор и любая среда разработки могли открыть и скомпилировать любой проект (созданный в другой IDE и для другого компилятора) целиком. Разумеется, каждая IDE может иметь свои «расширения» формата, не влияющие на суть проекта, но в том же xml можно спокойно это организовать.
    Что касается сред разработки — в них главное действительно то, что они должны работать. Дебаггеры обязательно нужны — иногда проще один раз пройти по шагам в отладчике, чтобы понять что неправильно в алгоритме, чем что-то там компилировать в уме. Ну и конечно, среды разработки должны быть легкими. И в смысле простоты использования, и в смысле потребляемых ресурсов компьютера. Много функций не надо — но те что есть, должны работать безупречно, не тормозить и не глючить ни при каких обстоятельствах.
    Писать же код в блокнотах, вимах и т.п. — если люди привыкли то почему-бы и нет, но приятнее все-же пользоваться специальными инструментами.
      +8
      Мейкфайлы, конечно, вполне себе ужасны. И тем не менее, язык мейкфайлов — вполне себе декларативный язык. Мейкфайлы описывают ациклический граф, в узлах которого — как раз ваши файлы в проекте. Иерархические файлы, зависимости, флаги компиляции — все это можно реализовать.

      По поводу формата файла проекта в стандарте языка. Для больших мейнстримовых языков: 1) поздно уже, поезд ушел. Да и на разных платформах — разные исторические традиции. 2) комитеты типа С++ никогда не договорятся; 3) всегда будут те, кому встроенный формат не подойдет, потому что не решит некоторых задач; 4) вместо того, чтобы сосредоточиться на разработке 1 языка, надо будет разработать 2 языка.
        +5
        Открываем любой мейкфайл — и видим if, else, case и т.д. Это не декларативность.
        Одна из причин, по которой мне нравится декларативность — как раз макимальная интеграция с IDE. Можно открыть опции в каком-нибудь редакторе свойств, список файлов доступен визуально и т.д.
        Да, в сложных проектах вероятно действительно нужен именно язык сборки, и скорее всего чисто декларативным проектом не обойтись. Я это прекрасно понимаю. Скажу честно — я не знаю как разрешить это противоречие. Но вероятно, нужно идти в сторону некоего структурированного файла, в котором информация по максимуму представлена в декларативном виде (и полностью доступна из IDE), а императивные фрагменты изолированы и написаны на чем-то более современном, чем то на чем написаны makefiles. Я не знаю, может быть javascript подойдет на эту роль и Qt Build System?
    –5
    Все правильно сказал. Особенно последний абзац.
      +61
      Разумеется, разработчик языка может позволить себе писать по 10 строк в день для программы, вычисляющей смысл существования вселенной. А остальным-то что делать, у кого ТЗ со 100500 различными и постоянно меняющимися бизнес-правилами, которые, как ни старайся, в 10 строк никак не запишешь. Тут и рефакторинг в IDE нужен, и средства для организации файлов в проекте.
        +23
        > Я помню времена, когда программисты отлично понимали друг друга. Каждый, кто умел программировать — знал как написать Makefile и bash скрипт. Сейчас же, человек который ничего не видел кроме Java и Maven входит в ступор, когда ему присылают Rake-файл.

        Джо Армстронг бурчит, как старушка у подъезда: "А вот при Сталине..." И c чего-бы вдруг Java-программист, использующий Maven, должен понимать Rake(!)-файлы.
          0
          С того, что Rakefile — довольно простая штука? Ну т.е. если Java-программист'у Rakefile не ясен хотя бы на 84%, то со словом «программист» надо что-то делать?
            –3
            Makefile и bash-скрипты — это базовые инструменты, обязательные к изучению.
            Другой вопрос, что идет подмена понятий.
            +35
            Тулы никогда не смогут заменить вам головы.
            Тулы, которые у нас есть сейчас, ничем не лучше тех что были 40 лет назад.

            Чистейшая демагогия.
              +19
              Ага. Навязывается ложная дилемма. Удобные инструменты никак не отменяют наличие головы. Более того, зачастую они позволяют освободить мозг от запоминания бесполезной информации, которую компьютер может по первому требованию посчитать на раз-два-три.
                +14
                И, к тому же, ложь. В современном IDE я могу сделать «find all references» на идентификатор и получить все его вхождения в программе. Я очень хорошо владею VIM, Emacs, ctags, grep и прочим легаси — так вот, с помощью них это сделать невозможно. Конечно, если речь идет о коммерческом проекте от мегабайта исходников и идентификаторе типа «name», а не о hello world в один файл, где уникальный идентификатор встречается три раза :).
                  +1
                  Не нужно так спешить, реализовать функционал «Find All Refernces» в emacs вполне возможно, мне кажется это и в VIM возможно, не берусь судить, я его не использую. И это сделать не так уж сложно.
                    +18
                    Я не спешу. Разработка программ — это то, чем я занимаюсь за деньги уже больше пятнадцати лет. Возможности VIM, Emacs и Visual Studio я знаю похуже авторов — но все равно очень, очень хорошо. Повторить в Vim или Emacs функциональность «Find All References» как она реализована в Visual Studio для C# или в JetBrains IDEA для Java имеющимися средствами невозможно.

                    Безусловно, можно с нуля написать анализ абстрактного синтаксического дерева нужного языка с учетом зависимостей, встроить расширением. И такие работы даже ведутся для связки emacs и clang, к прмеру. Но на данный момент указанное сделать невозможно. Я говорю про то, что сейчас есть, а не про то, что «теоретически можно написать». А «find all references» — это одна из самых простых задач, возникающих при работе с большой и сложной базой кода. Так что по моему скромному мнению, заслуженный разработчик эрланга лжет, когда утверждает что современные средства работы с исходным кодом «ничем не лучше тех, что были 40 лет назад».

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

                    P.S. С удовольствием использую и Vim, и Emacs, и мейкфайлы. Для работы с текстом и фрагментами. Но когда нужно работать с чем-то большим — потребны более сложные инструменты. И они есть. И они намного лучше тех, что были 40 лет назад.
                      +1
                      > Я не спешу

                      Нет, вы спешите.

                      > Возможности VIM, Emacs и Visual Studio я знаю похуже авторов

                      Это уж точно, судя по вашим выдумкам из параллельной вселенной далее по тексту

                      > но все равно очень, очень хорошо

                      Нет, очевидно что очень-очень плохо, по крайней мере что касается vim.

                      > Повторить в Vim или Emacs функциональность «Find All References» как она реализована в Visual Studio для C# или в JetBrains IDEA для Java имеющимися средствами невозможно.

                      Нет, не просто возможно, а она уже есть например в cscope и я её использую каждый божий день.

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

                      Не только можно, но уже написано. cscope называется и плагин для вима одноименный. Уже лет как… надцать. Уже для PDP-11 было, но вы же всего 15 лет разрабатываете, тем более судя по всему только в виндовс и вижуал студии и только на c#, — откуда же вам про это знать.

                      > Но на данный момент указанное сделать невозможно.

                      Можно, cscope/ctags. Всех устраивает вроде, если уметь использовать.

                      > Так что по моему скромному мнению, заслуженный разработчик эрланга лжет, когда утверждает что современные средства работы с исходным кодом «ничем не лучше тех, что были 40 лет назад».

                      Лучше, но это дает настолько несущественный выигрыш в производительности, что им вообще можно пренебречь. Я могу побыть примером тут. Работаю с кодовой базой Linux. Использую для навигазии vim+cscope. Рядом работает парень, который использует Eclipse. То что я вижу — у меня уходит столько же времени на то чтобы раскрутить аналогичный код. Так что да, все эти монструозные навороченные IDE с претензией на удобство, на самом деле суть те же редакторы кода, и не дают абсолютно ничего по сравнению с vim. Единственное — это что у них порог вхождения ниже.

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

                      Ох, вспомним про слона и Моську. Подозреваю что он поболее вас видел, и опыта у него явно поболее чем 15 лет в си-шарпике на венде, со «сложными большими коммерческими поделками».

                      > И они намного лучше тех, что были 40 лет назад.

                      Смотрел Eclipse — ни нашёл для себя ни одной возможности, которая была бы полезна и которой не было бы в vim в виде плагина или известной надстройки конфига.
                        0
                        Я могу побыть примером тут. Работаю с кодовой базой Linux. Использую для навигазии vim+cscope.


                        Что именно из кодовой базы, если не секрет? kernel?
                          +3
                          да, linux это и есть kernel. если подробнее — то я индексирую только файлы, существенные для используемой архитектуры (arm64) и нужной мне платформы, но это детали — по .config файлу вообще можно оставить только файлы, которые собираются для заданной конфигурации, но кому-то нравится чтобы были проиндексированы все файлы, чтобы можно было искать в них примеры кода. Всё тоже самое нужно делать в Eclipse — выбирать, какие файлы индексировать.
                            0
                            Замечательно. Подскажите старику, каким заклинанием cscope/ctags можно посмотреть все обращения к полю «next» объектов структуры «socket»?
                              +4
                                +1
                                flags меня более чем устроит.
                                  +2
                                  Для этого даже cscope не нужен:

                                  $ find. -name '*.[ch]' -exec grep -H 'struct socket ' {} \; | sed 's/:.*//g' | sort -u >cscope.files
                                  $ for i in $(cat cscope.files); do grep -PHn '\.flags\b|->flags\b' $i; done

                                  Если вам не нравится, что не все flags здесь будут именно из структуры socket, желаю удачи в отладке ситуаций когда синтаксический анализатор не «словит» присвоение типа такого:

                                  struct socket a = {
                                  .flags = 0x8,
                                  };

                                  или другое хитроумное, коих полно в сложных проектах на Си (например с использованием void*, container_of() и т.д.).

                                  С другой стороны, если у вас постоянно возникают такие ситуации (вот у меня за 2 года еще ни разу такого не нужно было, иначе бы я уже полазил и нашёл бы, как такое сделать, или сам дописал бы в тот же cscope), то никто не мешает в качестве синтаксического парсера (не IDE!) использовать парсер из Eclipse или clang, которые намного мощнее (но и намного дольше) чем cscope:

                                  eclim.org/
                                  lists.cs.uiuc.edu/pipermail/cfe-dev/2013-March/028452.html
                                    +6
                                    Поймите, я не против IDE как таковых, мой месседж в другом:

                                    1. vim настраивается до уровня IDE с помощью плагинов и настроек

                                    2. мне не понравилась категоричность и нигилизм ваших высказываний:
                                    — в сторону «дедушек» с 40-летним опытом разработки реально крутых проектов типа Джо Армстронга, польза одного проекта которых превосходит пользу от всех энтерпрайзных поделок на C#/Java вместе взятых. да и сложность я уверен тоже
                                    — в сторону инструментов типа vim и make, которые ну никак не устарели. да, на них нельзя тягать кнопочки на формочки, но что касается работы с кодом — они с ней справляются на 100%. ПО не портится и не гниет само по себе. задачи программирования почти никак не изменились за последние 50 лет, и способы писать программы тоже.

                                    3. IDE даже по сравнению с простым блокнотом + консольные тулзы (grep, find и т.д.) дают ВЕСЬМА малый выигрыш по времени, я имею ввиду суммарное время разработки проекта. я думаю это и был основной посыл Джо Армстронга, и я с ним согласен
                                      –1
                                      $ find. -name '*.[ch]' -exec grep -H 'struct socket ' {} \; | sed 's/:.*//g' | sort -u >cscope.files
                                      $ for i in $(cat cscope.files); do grep -PHn '\.flags\b|->flags\b' $i; done
                                      Серьезно?
                            +2
                            А есть готовые пакеты для такого счастья? Например vim со всеми настройками, плагинами и конфигами для нормального J2EE окружения (автодополнение, интеграция с maven/gradle, анализ стактрейса и т.д). Меня бы очень обрадовало не переучиваться назад на стрелочки с hjkl.
                              +2
                              Про J2EE не знаю, пишу только на Си/Си++. Для того что я делаю, — да, есть. sudo aptitude install cscope vim, и всё по сути, в самом виме уже есть плагин для cscope, подсветка синтаксиса, автодополнение (omni-completion), браузер файлов (:Sex, хотя я использую NerdTree), поддержка make (:make). Дальнейшие настройки, плагины — каждый себе по вкусу ставит и настраивает. Наверняка нет визуальной поддержки gdb по-умолчанию (уверен, что есть плагин), но ядро не так дебажат, так что не задавался вопросом.

                              Если вам нужно только h/j/k/l — может проще в вашей IDE поискать Vim режим или Vim-плагин? Потому что если вам кнопочки тягать на формочки — наверняка такого в vim нет и не будет, это ж вообще чисто консольный редактор.
                                +2
                                Юнит тестики на сервисики натягивать.
                              0
                              cscope/ctags умеет C. Язык с простой грамматикой. Что на счет C++ или Erlang? Ну и IDE тоже нужно уметь пользоваться, да
                                +1
                                Не теряйте контекст разговора. Говорили именно про Си, вот изначальная цитата «eyeofhell», на которую я отвечал:
                                > Я очень хорошо владею VIM, Emacs, ctags, grep и прочим легаси — так вот, с помощью них это сделать невозможно

                                Раз был упомянут ctags — очевидно разговор шёл именно о Си.

                                Пользоваться IDE я умею — 3 года просидел за QtCreator и KDevelop. В QtCreator на тот момент знал 95% функционала, т.е. все менюшки и настройки, и почти все комбинации клавиш. Да, такого парсера C++ как в KDevelop для вима я не видел, хотя на офф. сайте cscope пишут что он и C++ тянет, но опять же, разговор шёл про Си.
                                  0
                                  Ну а ниже он упоминал C# и Java, поэтому я думаю, что имелась в виду функция в принципе, а не применительно к какому-то отдельному языку.

                                  Возможно, вы знали QtCreator и KDevelop, но когда открыли Eclipse на посмотреть, то, очень может быть, вы просто не смогли оценить все его возможности.

                                  P.S. Лично я считаю, что Eclipse — неудобная и лагающая IDE, да и парсер QtCreator еще далек до идеала.
                                    +3
                                    «функции в принципе… не применительно к какому-то языку» не бывает и быть не может. у каждого языка своя семантика, и ни один IDE не умеет парсить абсолютно все языки.
                                0
                                cscope/ctags

                                Они отчасти неудобны тем, что приходится перестраивать теги при обновлении исходных файлов. Если редактор ещё может делать это автоматически для сохраняемых файлов, то при обновлённых при обновлении рабочей копии приходится не забывать это делать явно.
                                К слову, для C/C++ пользуюсь Emacs + GNU global + helm-gtag.
                                  +1
                                  Никто не мешает намапить обновление DB cscope в виме на сохранение файла. cscope второй раз и далее не переделывает DB, а обновляет. Из мана:

                                  cscope builds the symbol cross-reference the first time it is used on the source files for the program being browsed.
                                  On a subsequent invocation, cscope rebuilds the cross-reference only if a source file has changed or the list of source
                                  files is different. When the cross-reference is rebuilt, the data for the unchanged files are copied from the old
                                  cross-reference, which makes rebuilding faster than the initial build.
                                    +1
                                    Первое что нашлось:

                                    > I can't rebuild a database automaticly.

                                    If you really want to do that each time you save the changes to a file,
                                    you can use an autocommand something like this:

                                    au BufWritePost * call system(&csprg. " -R -b") | cs reset

                                    That's untested but uses pieces of commands I'm using currently, so it
                                    should work as is or with some minor tweaks.

                                    See

                                    :help 40.3 " Autocommands
                                    :help BufWritePost
                                    :help :call
                                    :help system()
                                    :help :bar
                                      0
                                      А теперь ещё раз прочитайте мой комментарий. Я знаю, что можно обновлять теги из редактора при сохранении. Более того, helm-gtags делает это за меня из коробки. GNU global умеет делать инкрементальное обновления базы для отдельных файлов. Я говорю о том, что файлы могут измениться не только вашим редактором.
                                        +1
                                        точно, не так понял. но и для такого случая можно что-то придумать. например как делает это Eclipse? по таймеру? ну так наверняка и в vim можно завести обновление базы по таймеру.
                                          +1
                                          Eclipse не использую, по поводу него затрудняюсь ответить. IntelliJ IDEA, похоже, следит за файловой системой через inotify и реактивно обновляет открытые файлы и индексы. Это требует много файловых дескрипторов, но в IDE всегда актуальная информация.
                                            0
                                            Именно. При нехватке дескрипторов IDEA рассказывает как увеличить их количество.
                                  +2
                                  Вы знаете, я тоже не 1-й год в разработке и меня ваш комментарий удивляет. Ну что ж, невозможно, видимо мы в паралельных мирах живем, в моем возможно. Более того, пугает ваша категоричность, потому конструктивный разговор с вами строить, вижу, не получится. Peace.
                                    0
                                    А чего там строить — показываете работающий «Find All References» для сложного C++/C#/Java/Python/Ruby с использованием emacs + ctags — и все, я снимаю шляпу и всячески вам благодарен. Я так сделать не могу и даже не представляю как. Потому как внутрь *tags смотрел и знаю как они работают. Легаси и современные средства работы с кодом — это две большие разницы. AST — это сила. Еще со времен LISP.
                                      +1
                                      показываете работающий «Find All References» для сложного C++/C#/Java/Python/Ruby
                                      А можно пример для последних двух (python, ruby) где-либо? Есть стойкое впечатление, что это не реализуемо в принципе, ни в редакторе с плагинами, ни в IDE.

                                      Например, имя вызываемого метода может строиться на основе входных данных программы, такой вызов в отрыве от конкретных данных не отслеживаем в принципе (т. е. его эвристически можно указать, как потенциальный вызов, но количество false-positive и false-negative слабо прогнозируемо). На конкретных данных — только при исполнении кода.
                                        0
                                        Ищите мой скриншот для Visual Studio и Python в этой теме.
                                          +1
                                          Между «всё работает» и «всё работает в тривиальном случае» большая пропасть.
                                            0
                                            ПО личному опыту «find usage» для python и ruby в Visual Studio и JetBrains'овских IDE последние пару лет работает хорошо. Refactoring понятное дело хуже, но пользоваться уже можно. Учитывая, что *tags не работают вообще — это, ИМХО, гоное подспорье в нашей нелегкой работе.
                                +1
                                Я вполне продуктивно работал с исходниками Хромиума как раз в виме. Более того, для проектов такого объема vim+ctags зачастую достаточно удобны и уж точно быстрее, чем современные навороченные ide.

                                +typo
                                  –1
                                  Если не секрет, над какой именно частью работали и в чем заключалась работа?
                                    +5
                                    Фиксил разнообразные баги, что как правило требовало немного врубиться в работу проблемного куска и некоторых окрестностей :) Много UI, но не только.

                                    Глубоко копал загрузку ресурсов, сетевые оптимизации (преконнект, префетч, пререндер) и особенности взаимодействия процессов в Хромиуме, сделал автоматическую перезагрузку «пофейлившихся» страниц при появлении соединения с интернетом a-la safari.

                                    Ранее использовал тот же инструментарий для копания в кодовой базе FreeBSD, делал подключаемую политику безопасности через Mac framework и для этого разбирался с работой некоторых механизмов ядра в части работы процессов и файловой системы. Также чинил некоторые юзерспейсные утилиты.

                                    Справедливости ради надо признать, что все это очень качественно написанный код с разумной структурой. Если бы вместо этого была бы макаронная портянка, могло и не получиться.
                                      –1
                                      Специфические кейсы. Багфикс, если не большой архитектурный баг, требует как раз изучения конкретных кусков без всей остальной туши кода. А вот расширение функциональности уже треует изучать не только как это реализовано здесь — но и как оно используется.

                                      Линукс кернел — это C. Для него и cscope нормально работает, там же кроме макросов ничего неприятного нету, если напрямую память не кастить.

                                      Согласитесь, от задачи зависит. Find All Reference — вполне себе хороший, годный, часто встречающийся кейс которого 40 лет назад нифига не было.
                                        +2
                                        Специфические кейсы.

                                        ИМХО довольно типичные. Что исправление багов, что расширение функционала требует понимания интимных взаимоотеношений различных сущностей, определенных в разных местах кода. Вы не поверите, часто даже тупой grep оказывается годным решением для find all references (или я вас не понимаю).

                                        А вот глобального рефакторинга мне делать не приходилось, заочно признаю превосходство современных IDE на этой задаче.
                                          0
                                          Вы не поверите, часто даже тупой grep оказывается годным решением для find all references (или я вас не понимаю).


                                          Охотно поверю. Сам много над чем работал и ack люблю. Я больше про большие проекты, когда нужно найти name у во-о-о-он того класса, а разработчики как обычно любят генереки, шаблоны и абстрактные фабрики. В таких, частых в энтерпрайзе и автоматизации, раскладах, IDE творят чудеса и позволяют не срывать сроки. По крайней мере сильно :).
                            +9
                            Сейчас постоянно использую Makefile при работе с ndk в Android. Не скажу, что они прям настолько ужасны. Они могут показаться страшными только при первом знакомстве.

                            Понятно, что Make-файлы лишь как один из примеров, но всё же.

                            «Проблема не в самих тулах, а в том, что когда они сломаны, все время уходит на то чтобы их починить.»
                            Проблемы не в тулах, а в самих программистах )
                              +7
                              Ну и что, в Java есть еще Ant, как альтернатива декларативности Maven, и чем-то напоминающий make. А еще есть Gradle со смесью того и другого. Печально, что автор языка не желает признавать того, что инфраструктура Erlang неразвита.
                                +1
                                Из популярного есть ещё ivy.

                                Не поминайте ant всуе. То вспоминается сборка apache solr, использующая одновременно ant, maven и ivy.
                                  0
                                  Ант был хорош для своего времени. Сейчас он уже не потянется с современниками, но этот проект уже давно живет багфиксами.
                                +26
                                Ответ просто удивителен. Зачем вам перфоратор, если можно взять ручную дрель, и неторопливо, по миллиметру в час двигаться к цели? Зачем вам бензопила, если тот же результат можно получить, используя ножовку?

                                Я тоже помню времена, когда нужно было знать тьму математики. А сегодня можно запрограммировать игру с трёхмерной графикой, даже понятия не имея, что такое кватернионы и матрицы. И больше людей сможет сосредоточиться на разработке самого продукта, а не на технических деталях. Какая досада, правда...?
                                  –2
                                  Блин. А я думаю почему современным программистам гигагерц нескольких процессоров и десятка гигабайт памяти не хватает на то, что раньше на мегагерцах и мегабайтах работало очень хорошо?
                                  Ан вон оно что, не надо «знать тьму математики», не надо сосредотачиваться на «технических деталях», а надо «на разработке самого продукта». То есть разработка продукта не ради продукта, а ради разработки.

                                  P.S.: Извините, наболело.
                                    +2
                                    Может, это не программисту не хватает, а пользователю?
                                    Попробуйте ради интереса включить графический режим 320x240 и представьте, что вам в таком работать целый дель.
                                    Зато на мегабайтах и мегагерцах.

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

                                      Какие информационные возможности нужны, например для notepad? Размер 193536 байт
                                      Или, например, mspaint.exe 6,676,480 байт. И это только .exe код, без dll-ей.

                                      Давайте будем честными с самими собой и скажем, что да, сейчас мы пишем программы в угоду скорости разработки. Плюс сейчас средний программист не так умен, как было когда-то. Плюс к этому современная аппаратная база позволяет.

                                        +1
                                        Блокнот — 86 килобайт кода. Остальное ресурсы.
                                        Пейнт — 600 килобайт код + ресурсы.

                                        Собственно размер ресурсов (которые значки, курсоры, картинки) напрямую зависит от разрешения экрана.
                                          0
                                          Ок. Не будем рассуждать много это или мало — 86 килобайт кода для блокнота, в котором используется только стандартные элементы управления и логики на чуток.

                                          Мне больше интересно Ваше мнение на первый вопрос. Вы тоже считаете что из-за высокого разрешение экрана не стоит заморачиваться на математике и разработке?
                                            +2
                                            при средней длине инструкции в 4 байта, это 20 тысяч строк ассемблерного кода. Что весьма не много (не забываем, что у 16тиразрядных процессоров инструкции короче были).

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

                                            Дополнительно, требования к портируемости приложений в последнее время сильно возросли. Если 30 лет назад ваша программа должна была корректно работать на одном компьютере — на котором вы ее написали, то теперь у нас есть 2 семейства операционных систем х 3 семейства архитектур процессоров. Поэтому грязные хаки уже канают.

                                            Программное окружение, в котором работает ваша программа, также заметно изменилась. Теперь ваша программа не может распоряжаться всем оборудованием (и безнаказанно стащить все ваши пароли и удалить систему), ей приходится соблюдать правила, и это тоже доп. код.

                                            Конечно, все не должны заниматься математикой! Если вместо того, чтобы дело делать, каждый будет свой графический движок велосипедить, то качество продуктов упадёт, и на много.
                                              0
                                              Все, что Вы выше написали про грязные хаки и оптимизации по скорости, это все про notepad?

                                              Про «недолжны заниматься математикой».
                                              Лично у меня «заниматься математикой» не означает «велосипедить графический движок», как и вообще что-то велосипедить. Для меня это, в первую очередь, означает хотя бы знать, что время произвольного доступа к элементу односвязного списка будет зависеть от длины этого списка. Вот даже такая мелочь современным программистам неведома порой. см.http://habrahabr.ru/post/206338/
                                              И вот из-за таких мелочей возникают те проблемы, о которых я писал в своем первом комментарии.

                                              Всё то, что Вы написали
                                                0
                                                Грязные хаки, и оптимизации компилятора, конечно, и к блокноту относится!

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

                                                вот из-за таких мелочей возникают те проблемы, о которых я писал в своем первом комментарии
                                                Так где они возникают-то? Примеров-то вы так и не предоставили.
                                                  0
                                                  Ок. Ради чего нужны грязные хаки и оптимизации компилятора для блокнота?

                                                  Во-первых про квартерионы и матрицы писали не мне. Посмотрите, пожалуйста, наверх. Автор никому конкретно не адресовал свое послание. Во-вторых, причем тут квартерионы и матрицы? Я автору тому комментария писал про нужность хотя бы основ математики для программирования. Вы хотите поспорить с тем, что программисту математика не нужна?

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

                                                    А кто с вами спорил по поводу того, что основы алгоритмов программист должен знать? Речь шла про весьма специфическую и более сложную математику. А то, что вы по-своему поняли…
                                                      0
                                                      :) Это меня своеобразно поняли. Замучали программы, которые делают мало, а требуют мегабайты.
                                          +2
                                          То есть вы утверждаете, что с ростом разрешения графического режима можно не заморачиваться математикой, сконцентрироваться на разработке и это нужно пользователю?

                                          Вы зря привязываете математику к размеру кода. Например, сложные, но быстрые структуры данных, которые реализуются в STL, занимают десятки килобайт на каждый контейнер. А если тупо написать всё циклами большой вложенности, получится пара килобайт, но работать будет на порядки медленнее.

                                          Какие информационные возможности нужны, например для notepad?

                                          Одно слово — юникод. Редактор с возможностями блокнота малореален на старых ЭВМ, потому как только карты типа символа (цифра, буква и т.п.), таблицы соответствия строчной и заглавной, всё это занимает мегабайты.
                                            0
                                            :) Я все никак в толк взять не могу, каким образом у Вас из утверждения:
                                            «То есть вы утверждаете, что с ростом разрешения графического режима можно не заморачиваться математикой, сконцентрироваться на разработке и это нужно пользователю?» получилось утверждение «привязываете математику к размеру кода»?

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

                                            Это слово Unicode — поддерживается в OS (Операционной системе) для всех программ и не занимает ничего (или почти ничего) в коде программы. Вы в самом деле верите, что notepad имеет личные таблицы локалей? Да даже если и так, они бы были в ресурсах, как мне кажется.

                                            P.S.: А если уж из-за чего кодовая секция блокнота распухла, так от прилинкованной к нему стандартной библиотеки. Будет время, посмотрю IDA.
                                              0
                                              Вас не удивляют операционные системы, которые тормозят на последнем железе или маленькие (по функциональности) программы, которые требуют для запуска самолет?

                                              Факты говорят о другом. Когда-то я пользовался Windows 2000, Windows 2003, эти системы загружались по 3-4 минуты.
                                              Сейчас Windows 8 загружается 10 секунд. Быстрее специализированного linux-роутера.

                                              Это слово Unicode — поддерживается в OS (Операционной системе) для всех программ и не занимает ничего (или почти ничего) в коде программы. Вы в самом деле верите, что notepad имеет личные таблицы локалей?

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

                                              Вы не подумайте, я ещё на ZX-Spectrum кодил, и задача впихать в часть видеопамяти дебагер+дизассемблер мне знакома. Но сейчас такие задачи смешные. Да, они решаются тупо в лоб менее оптимально, чем в те времена. Но это потому, что впереди намного более сложные и интересные задачи, которыми нужно заниматься, а не сидеть в песочнице, перекладывая килобайты.
                                                –1
                                                :) А как вы часто системы грузите? Вот вам сильно помогает что Windows грузится по 10 секунд? Мне лично надо чтобы система нормально работала.

                                                А вот когда система только что стартовавшая уже сьела 3.6 Gb памяти, и при это еще что-то жующая — это вас не удивляет? Припарка в виде SSD проблему частично решила, до тех пор, пока не загрузил PyCharm + еще что-то написанное на Java и вот уже 8Gb RAM кончились :)

                                                То что сейчас легко делает блокнот, можно было легко сделать в редакторах эпохи 90-x.

                                                Хм. А интересно зачем впихивать в часть видеопамяти дизассемблер + дебаггер? ;)
                                                Или так STS работал? (уже не помню)
                                                Был же и Scorpion с теневым монитором и много чего еще :)
                                                  0
                                                  пока не загрузил PyCharm + еще что-то написанное на Java и вот уже 8Gb RAM кончились :)

                                                  Ну и пусть кончилась. Я точно скажу, что производительнось работы в VS2013+R# выше, чем в любом редакторе из 90-х (несмотря на минутное ожидание загрузки большого проекта, но ведь «А как вы часто xxx грузите?»). Да, иногда я Delphi запускаю, но счастья в виде реактивно быстрой IDE что-то и не хочется, когда там даже goto definition работает далеко не на всех символах.

                                                  Хм. А интересно зачем впихивать в часть видеопамяти дизассемблер + дебаггер? ;)

                                                  Защиты часто всю память съедали, только на экран не покушались. Да и игры тоже на всю память претендовали. Перед запуском, чтобы покопаться нормально, только в экран грузить код.

                                                  Или так STS работал?
                                                  Это другая история, 128K :)

                                                  Был же и Scorpion с теневым монитором и много чего еще :)
                                                  Скорпион дорог и малораспространён. Рулят свои ROM-ы c выходом в отладчик по NMI
                                                    0
                                                    Я не более недели назад на своей шкуре ощутил, что никакой редактор не заменит vim, к которому привык. В vim при должном умении и знании что писать, все пишется просто очень быстро! Как нибудь посмотрите как мастера пишут на vim-е, _насколько_ быстро получается.

                                                    Понятно. У меня последним спектрумом был Scorpion. Мне были неведомы эти проблемы.

                                                    У нас кроме Scorpion-а ничего больше не было. Ну, или как вариант, брали Ленинград-2 48к, напаивали на него AY8912, РУ-ки (уже не помню 5-ые наверное), ВГ93 и получали свои 128к.
                                                      0
                                                      Кому vim незаменим, а кому FAR ))
                                                    +2
                                                    Вы хотя бы разберитесь что ли, как работают менеджеры памяти Windows и Java. Уже сколько раз это обсуждалось! И на хабре было!
                                                      0
                                                      :) А зачем? Вы можете мне обьяснить чем знание того, как работает программа изнутри поможет мне решить мои пользовательские проблемы?
                                                        0
                                                        Затем, что для того, чтобы делать выводы из высоты столбика занятой памяти, вы должны представлять, что же этот столбик на самом деле показывает, как его показания нужно интерпретировать и как система себя будет вести при изменении этой самой высоты столбика.
                                                          0
                                                          Ок. Ну интерпретировал я, что некому жава софту нужно 2 гига памяти чтобы мне рисовать 6 графиков и показывать кусок лога на экране. Что дальше? Вгрызаться в него декомпилятором чтобы выяснить, какого там происходит?
                                                            0
                                                            а зачем Джаве собирать мусор и тратить на это ваше время, если памяти все равно хватает?
                                                              0
                                                              : Э… 7.6 Гб занятой из 8 Гб.
                                                              При этом чувствуется что система стала замирать и тормозить. Это хватает? Как у жава устроено внутри проверять что памяти хватает?
                                                                +1
                                                                да хоть пусть все 8 будут заняты — от пустующей памяти толку тоже нет никакого.

                                                                Как у жава устроено внутри проверять что памяти хватает?
                                                                ну так вот и предлагается это выяснить) и, возможно, помочь ей. Я на счет джавы не могу сказать, а вот видна будет держать память до последнего, чтоб по возможности ее переиспользовать.
                                                                  0
                                                                  Ну так мне тоже все равно, пусть хоть всю память держит, я на столбик занятой памяти не смотрю, меня больше волнует что система тупит. Освобождаю память до 7.1 и все ок.
                                                                  0
                                                                  Ну чтобы хотя бы знать что можно задать IDE -Xmx, что ли…
                                                            +2
                                                            Если знать, что под капотом, можно эффективнее пользоваться.
                                                            Например, с 5-й скорости автомобиль не разгонять ))
                                                              0
                                                              Судя по вашей аналогии мне надо ставить второй компьютер чтобы пользоваться двумя жава программами. Тоже вариант. Спасибо
                                                      0
                                                      Да, я согласен. Мы размениваем мегабайты на быстроту и удобство кодирования.
                                                      Но это оправдано — без такого размена мы бы не достигли тех высот, на которых мы сейчас.
                                                      Не согласны? Напишите свою ось на ассемблере и попробуйте поконкурировать с разжиревшими мейнстримными.
                                                        0
                                                        Опять Вы не про то. Я одно, мне в ответ список мемов «ось на ассемблере», «оптимизация всего и вся», «велосипедостроение». Я про это не говорил!

                                                        Берите пример с раннего IPhone-а, которому удавалось на относительно скромном железе показывать офигительные результаты. Что мешает это делать на обычных ОС? Тем что «батарейки» не ограниченные и память докупить просто?
                                                          0
                                                          Возьмём HTC Sense, который только ленивый не ругает за жир и тормознутость.
                                                          Но в состоянии «с завода» он работает ровно как первый айфон, ничего не тормозит, и звонит прекрасно. А вот стоит поставить анимированные обои, улучшалки интерфейса, google maps (и кучу других «социальных» сервисов, которые в автозагрузку прописываются) — и уже тормоза начинаются.

                                                          Аналогично, я думаю, с «обычными» ОС.
                                                          Хочешь R# на MSVS — проекты начнут тормозить при загрузке, но это окупится многократно.
                                                            0
                                                            Я же приводил в пример IPhone. Про Андроид то я в курсе.
                                                            IPhone был стоящим, да тоже стал портиться потихоньку.
                                                              +1
                                                              Был стоящим, пока был негибким. Стоит туда пустить приложения, стартующие с системой, анимированные обои — и привет, память кончилась. Можно в пример и Symbian поставить, какая она была шустрая ))
                                                                0
                                                                так может лучше сделать приложение/OS негибким но достаточным? Разве дело что свистелки убивают систему?
                                                                  +1
                                                                  Было, не выдержало конкуренции, погибло.
                                                                  Впрочем, никто не запрещает пользоваться первым айфоном или даже симбианом. Почему нет?
                                                                    0
                                                                    что и делаем
                                                +3
                                                Вы можете привести пример того, что раньше работало на мегагерцах и мегабайтах, а теперь требует гигагерцы и гигабайты? При равных возможностях.
                                                  0
                                                  Драйвер мыши. Раньше это был килобайт, ну два кода. Ну памяти сколько там могла отьесть резидентная программа для своей работы? Килобайт 16?

                                                  А вот сейчас висит у меня ipoint.exe (Microsoft IntelliPoint)
                                                  Сам весит 2328944 байт. Памяти жрет 24 мегабайта. На что? :)
                                                  При том что все функции для поддержки мыши уже есть в OS. Загадка.
                                                    +1
                                                    Ну там же не драйвер, а всякие свистелки место занимают. Я так полагаю, что можно просто воткнуть мышь и вообще ничего не делать. Будет работать нормально же все. Опять же, если посмотреть, что там внутри в пакете, то сами драйвера занимают порядка 50 КБ (30КБ кода для x64). Можно только их и поставить. Только конфигурить придется, видимо, как в старые добрые времена, через regedit :)

                                                    В общем, не подходит под пункт о равных возможностях.
                                                      0
                                                      Нет никаких свистелок — есть иконка в трее в котором есть только один пункт «Exit».

                                                      И драйвера я сам не ставил. Воткнул мышь, она определились как мышь от MS. Win7 полезла в интернет, сдернула драйвера, после чего в системе появился процесс ipoint.exe.
                                                      Для чего он нужен — мне неведомо. Как пользователь буду ли я забавляться с регедит-ом? Да даже как непользователь не буду, быстрее другую мышку найти.
                                              –1
                                              сейчас 2014-ый, а мы все еще используем Vim
                                              С таким программистом дальше разговаривать просто не о чем.
                                              «Сейчас 2014, а мы все еще составляем слова из букв.»
                                                +3
                                                Простите, а вы вообще работали с IDE типа JetBrains IDEA?
                                                  +2
                                                  Прощаю, работал. И что?

                                                  Я еще на пхп когда-то писал, чего уж там.

                                                  Кто без греха, пусть кинет камень.
                                                    +1
                                                    Простите, я вот работаю в IDEA, но без IdeaVim-плагина работы не представляю. На коллег, постоянно в той же Idea пользующихся мышкой, больно смотреть.
                                                      +4
                                                      Функционал редактора и функционал среды разработки ортогональны. Программа может быть никаким редактором, но предоставлять кучу функций по работе с кодом. Также может быть так, что редактировать текст в ней потрясающе удобно, а вот фич для упрощения разработки — кот наплакал. Вим — это как раз второй случай. Я тоже пишу в идее исключительно с помощью IdeaVim, и без вимоподобной раскладки не представляю себе удобного редактирования текста. Но сам вим, как бы крут он не был для редактирования, не заменит полноценную среду. Вышеприведённый пример с «Find all usages» очень показателен. А ведь это только одна из функций. Другой типичный пример, характерный для Java — перемещение класса в другой пакет. В среде это пара кликов мышкой (или пара горячих клавиш, если настроено). А в случае вима это перемещение файлов вручную и изменение целой кучи других файлов, которые использовали перемещаемый класс. В проекте, где число классов близко к тысяче, это просто невозможно сделать без ошибок. И опять же, это только один из множества примеров.
                                                        0
                                                        Разумеется, ортогональны. Причем подойти к вопросу можно и с другой стороны: есть, например, такой проект, как eclim, интегрирующий headless eclipse в vim.
                                                        0
                                                        Я, большой любитель Vim считаю IDEA «близким» к нему по подходу хоткиз, ибо 95% действий в Идее можно сделать с помощью клавиатуры (конечно с возможностями редактирования не сравнить, но скажем ctrl+w вполне неплохо заменяет, а иногда и лучше, чем v+i+w)
                                                          0
                                                          Да, в IDEA все хорошо с хоткеями, мышка вообще не нужна. Но редактирование кода (а подавляющую часть времени в IDE мы пишем код) с vim-плагином намного эргономичнее — невозможно все возможности вима уместить на хоткеях с модификаторами, без введения режима команд (либо получатся такие хоткеи, что за пару месяцев работы заработаешь туннельный синдром).
                                                      +2
                                                      Некорректное сравнение.

                                                      Сейчас 2014 год, но часто ли мы используем пергамент и чернила, пишем пером? Вообще пишем вручную, а не клавиатуре? Используем почтовых голубей? Буквы — да, буквы остались. Способ записи и передачи букв изменился.
                                                        –3
                                                        Вот это действительно некорректное сравнение. Клавиатура обычно быстрее и эффективнее каллиграфии. Vim обычно быстрее и эффективнее IDE.

                                                        И да, безусловно, есть определенный шарм в том, чтобы писать пером, или отправлять всякие вещи почтой России почтовыми голубями, или ждать пока запустится IntelliJ. Отлично, когда есть выбор, не правда ли?
                                                          +7
                                                          Я сам долгое время разрабатывал сайты на PHP из Notepad++, даже аргументировал похоже, мол, пока эта IDE загрузится, я пол класса напишу))

                                                          Но когда дошел до крупных, даже КРУПНЫХ проектов, осознал, как круто иметь возможность видеть автоматические подсказки по методам и аннотации вслпывающие, подсказки по методам и классам, как удобно рефакторить в IDE-шке… Ух. Это не мешает мне иногда использовать тот же блокнот для быстрого редактирования какого-то файла, но IDE помогает мне не держать в голове то, что она может быстро показать или подставить сама.

                                                          Я сейчас разрабатываю под android, в той же, и она меня IntelliJ IDEA 13 дико радует. Например, редактор XML-ек с версткой экранов. Можно даже не пользоваться визуальным редактором и писать XML-ку руками — но всё равно тут же видеть превьюшку. IDE мне настучит по рукам, если я попробую использовать параметр доступной только с API Level 19, когда я сейчас пишу под 11 и т.п. Не нужность держать это в голове, отдать рутину машинке, освободить больше процессорного времени мозга для разработки бизнес-логики — разве это не оптимальный подход?
                                                            +5
                                                            Я сам долгое время, слушая людей вроде вас, пытался пересесть на IDE с emacs, потому что аргументы вида «пока эта IDE загрузится, я пол класса напишу» мне казались сомнительными.

                                                            Но когда я дошел до крупных, не более 500 000 SLOC, осознал, что для динамических языков так ничего путного в плане автодополнения не придумали, что расписывать везде в аннотациях "var SomeClass" отнимает время, сравнимое с плюсами от автодополнения. Так же я с удивлением обнаружил, что умное автодополнение почти бесполезно — в случае, если вы не знаете, что находится в классе, вам придется все равно перескакивать на его реализацию, чтобы полазить по нему, а если знаете, то вам будет достаточно самых примитивных систем дополнения кода, доступных в vim и emacs. Еще я заметил, что даже на процессоре 4,1 ГГц и 8 гигабайтах оперативной памяти скорость работы IntelliJ( и производных от него) не дает той отзывчивости и комфорта, который дает Emacs.

                                                            Но если бы мне пришлось писать под android, то я бы безусловно выбрал IDE. Просто потому, что она оградила меня от ошибок, ввиду моего полного профанства в этой области.
                                                              0
                                                              Я просто не работал с vim, но работал с редакторами с подсветкой синтаксиса, типа Notepad++.
                                                              Vim умеет по команде перейти в реализацию нужного метода? (сам найти и открыть требуемый файл)? Показать все реализации, если мы находимся в интерфейсе, например? Показать все «перекрытия метода вверх и вниз»? (перейти к наследнику, в котором метод заново реализован/предку в длинной иерархии классов) Я правда просто не знаю, есть ли там все эти пользительные возможности.
                                                                +1
                                                                Сам — нет. Для этого он использует т.н. «tag files», которые сооружаются сторонними утиитами: ctags, cscope, clang tags итд. К сожалению, делают они это небыстро, в общем случае по команде и при работе в фоновом режиме проблемы. А сама функциональность прыгания по файлам и отображения completion/search result списокв есть конечно :).
                                                                  +2
                                                                  Все так.
                                                                    +1
                                                                    1. cscope строит базу ядра по времени намного быстрее Eclipse
                                                                    2. cscope делает быстрое перестроение при уже построенной базе
                                                                      0
                                                                      У него есть некоторые проблемы с фоновым режимом работы, потому как VIM немного однопоточный. Приходится извращаться с порождением фоновых процессов и взаимодействием через пайпы, что негативно влияется на все. Там же Visual Studio почти все делает в фоновом режиме. Особенно с Visual Assist и Resharper.
                                                              0
                                                              Vim обычно быстрее и эффективнее IDE.


                                                              При редактировании текста — да. Когда нужно работать именно с исходным кодом и проводить сложные операции над AST вида «переименовать вот это поле для всех экземпляров вот этого класса во всех двадцати мегабайтах нашего проекта» — нет.
                                                                +6
                                                                Последний раз когда этот аргумент попадался мне на хабре, мне удалось выяснить, что подобная операция была востребована, когда компания покупала чей-то продукт, и нужно было перестроить схему иерархию классов продукта в соответствии с иерархией классов самой компании. И да, в таких ситуациях редакторы абсолютно бесполезны. Другое дело, что такая задача весьма специфична, и занимает примерно 1% времени от работы среднего программиста, а все остальное время приходится «редактировать текст». Конечно я допускаю, что вы можете поддерживать некую огромную ERP систему написанную индусами и удачно взлетевшую, из-за чего ваша команда все время занимается вялотекущим рефакторингом, но таких случаев на моей памяти исчезающе мало.
                                                                  +9
                                                                  Конечно я допускаю, что вы можете поддерживать некую огромную ERP систему написанную индусами и удачно взлетевшую, из-за чего ваша команда все время занимается вялотекущим рефакторингом, но таких случаев на моей памяти исчезающе мало.


                                                                  Расскажу. Так как я кроме основных команд еще часто консультирую другие компании, то есть наблюдения. Типичная начальная ситуация — когда 1-2-3 разработчика пилят проект. Они знают базу кода, код боллше пишется чем меняется, все хоршо. Через три года, когда двое из них уже уволились, оставшийс стал тим лидом и наняли еще три команды по 10 бойцов начинается ротация кадров. И вот тут-то, как бы хороша не была архитектура, новым разработчикам приходится ее изучать. Для этого нужно как минимум «Find all references». А также раотающий «go to definition» (который, между прочим, в реальной жизни даже в Visual Studio не работает, приходится сверху Visual Assist докупать) и прочие радости раоты с кодом как с кодом, а не с текстом.

                                                                  Рефакторинг же часто требуется для устранения технического долга между релизами и поддержки более сильными разраотчиками менее сильных. В ряде случаев это дешеле и эффективнее, чем pre-commit code review. Но это, в целом, не критично. А вот find all references, go to definition и прочее — критично.
                                                                    +2
                                                                    К слову go to definition и find all references могут быть настроены в vim и emacs. Для языков поддерживающих ctags и gtags. Я про более изощренные манипуляции с кодом хотел бы узнать, насколько востребованы они.

                                                                    Рефакторинг же часто требуется для устранения технического долга между релизами и поддержки более сильными разраотчиками менее сильных.


                                                                    А какая группа языков используется? И насколько плохи «менее сильные» разработчики? Каков объем проектов?
                                                                      0
                                                                      Для языков поддерживающих ctags и gtags.

                                                                      Интересно, эти xtags помогут текстовому редактору отличить в контексте выражения глобальную переменную от локальной, просканировать только те неймспейсы, которые подключены в using, чтобы перейти к правильному definition, а не к первому похожему?

                                                                      В общем случае, нужно применить препроцессор и построить синтаксическое дерево по всем правилам языка, иначе ложные срабатывания обеспечены.
                                                                        +2
                                                                        Нет. Там очень тривиальный анализатор, который от грепа отличается только понимаем что такое область видимости и простейшим набором трюков, которые можно применить на plain text без разбирания ast и зависимостей.
                                                                          +2
                                                                          по-моему зря этот Джо сюда Java прилепил, она совсем из другой оперы, и отсюда холивар весь.

                                                                          кто-то может привести пример инструментария для языков с _динамической_ типизацией где всякие go to definition и find all references, дают сколь-нибудь существенное отличие в надежности результата, по сравнению с «тупым грепом»?

                                                                          мне вот не попадались еще. поэтому да, на первый план, так или иначе, выходит удобство редактирования и «vim» — наше всё. остальные трюки приходится делать лапками и внимательно проверять глазками.
                                                                            0
                                                                            Python, Visual Studio 2013, «find all references» на определение «a» в конструкторе Foo. Сложнее можете сами поиграться, все бесплатно и доступно для скачивания с офсайтов:

                                                                              +2
                                                                              мм. а если так? :)
                                                                              def factoryMad(): 
                                                                                   return random.choice([Foo, Bar])
                                                                              
                                                                                +1
                                                                                Так, конечно, не найдет. Потому что random C-шный код, и никто не знает что он возвращает. А вот так — найдет:

                                                                                def factoryMad(): 
                                                                                	if 1:
                                                                                		return Foo
                                                                                	else:
                                                                                		return Bar
                                                                                
                                                                                  +1
                                                                                  мне кажется, что random на любом языке плохо поддается статическому анализу ;)
                                                                                    0
                                                                                    Не в этом дело. Реализация в C-шном коде. В AST нет путей. С этим в целом тоже можно работать, но Python Tools for Visual Studio еще жостаточно молодой проект и advanced механизмы еще не все есть. Но то что есть лично мне вполне нравится и работает.
                                                                                  0
                                                                                  я хотел сказать, что в реальных проектах, возможности языка используются на полную катушку — со всяким мета-программированием, и прочей ерундой, которая делает язык именно таким, за что мы его и выбираем, а статический анализ — лишь приятной примочкой (типа на PEP8 чекать). автоматический рефакторинг в каких-то частных случаях тоже возможен, но поменять мегабайт индуистического кода неглядя, как для Java — это фантастика (или безумие).
                                                                                    0
                                                                                    Еси какакая-то тулза автоматически решает задачу в 95% случаев, а в 5% за ней нужно немного подправить руками — то меня такая тулза вполне устраивает, пока альтернатива — править руками все с шансом на ошибку большим, чем у автоматики тулзы.

                                                                                    А вот VIM с ctags такого не может в принципе, как ни крути.
                                                                                      +3
                                                                                      VIM c ctags (пусть wrangler если это erlang) решают задачу в 95% случаев. остальные 95% кода все равно лапками проверять. не понимаю с чем вы не согласны.
                                                                                        0
                                                                                        С тем, что VIM + ctags могут сделать адекватный «find all references» в большом и сложном проекте на C++, C#, Java, Python, Ruby
                                                                                      +1
                                                                                      Да и на java тоже. Как только выходим на уровень интеграционного функционала или метапрограммирования (то же aspect-oriented programming) — только с подробным тестированием, как дедушка Фаулер завещал ,)

                                                                                      Банальный пример: использование IoC-контейнера дает позднее связывание (часто в рантайме) и при рефакторинге от IDE требуется «понимание», как работает конкретный контейнер, чтобы не нарушить его работу.
                                                                                    +1
                                                                                    Аналогичные эвристические алгоритмы работают и в семействе IntelliJ. Но как доходит до простого метапрограммирования (на ruby, python, js — не суть), начинаются проблемы.
                                                                                      0
                                                                                      Редактор питона в Visual studio, кстати, действительно хорошо сделан и его постоянно улучшают.
                                                                                        +4
                                                                                        Для питона сейчас активно развивается проект github.com/davidhalter/jedi (я использую в комплекте с Emacs github.com/tkf/emacs-jedi ). Работает прекрасно, не тормозит.
                                                                                        Features тут jedi.jedidjah.ch/en/latest/docs/features.html
                                                                                    +1
                                                                                    Я прекрасно понимаю, что для того, чтобы работал рефакторинг, 100% правильный переход по символу нужен ast. Я просто говорю, что часто в таких инструментах нет необходимости для того, чтобы продуктивно работать с кодом. В смысле даже в проектах с сотнями классов и интерфейсов можно комфортно работать с весьма, по вашим меркам, примитивными инструментами.
                                                                                      0
                                                                                      А для части языков и ast недостаточно. Начиная с метапрограммирования на всяких ruby, python, javascript; AOP на java (хотя, там есть плагины типа ajdt для eclispe и aspectj support для idea). Конечно, делают плагины для конкретных языков и фреймворков, но сейчас часто итоговая структура собирается только в рантайме.
                                                                                        0
                                                                                        Э… Как? Вот взяли нового человека в команду… Ну пусть какую-нить внутреннюю CMS крупной компании допиливать. Java, десять мегабайт кода (очень много GUI и три вагона логики, отчетов всяких, аналитики, интеграции с другими программами). Вот он ползает по коду и видит Странный Класс. Со Странным Методом. И нужно ему для понимания процесса выполнить запрос «все фрагменты кода, где выывается этот метод». Как это сделать с примитивным инструментом?
                                                                                          0
                                                                                          Опишите пожалуйста ситуацию в которой для понимания процесса нужно искать вызовы указанной функции. Если мне нужно разобраться как что-то работает, то я обычно ищу сверху вниз, погружаясь в реализацию.
                                                                                            +1
                                                                                            Да пожалуйста. Человеку нужно поменять функцинальность модуля. Он его видит первый раз в жизни. Смотрит на методы — это понятно, это понятно. А вот это — непонятно. И с комментарием тоже не понятно. Простейший и самый б быстрый способ разобраться — «find all references» и посмотреть как и где ЭТО используется в коде.

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


                                                                                            Сверху вниз на 10-мегабайтной CMS — это как и откуда? O_O
                                                                                              +1
                                                                                              Что значит поменять функциональность модуля? Перед человеком ставится какая-то конкретная задача, а не «где-то что-то поменять». И постановка задачи во много определяет ее решение. Пока могу вам ответить, что для того чтобы это сделать нужно «где-то как-то разобраться».

                                                                                              Сверху вниз на 10-мегабайтной CMS — это как и откуда? O_O


                                                                                              Точка входа зависит от того, что нужно будет выяснить. Или вы о чем-то другом?
                                                                                                0
                                                                                                Типичная задача — «вот тебе модуль, имплементирующий таск в JIRA такой-то и дополнительные задачи такие-то и такие-то» (это видно по blame). Вот следующая задача в JIRA — нужно что-то поменять, к примеру модуль оперирует одной бизнес-сущностью, а нужно модифицировать его и систему так, чтобы оперировал еще и другой. Типичная, рядовая задача. Требует рефакторинга всего модуля по диагонали и скорее всего ряда мест, где он используется. Вперед, и главный критерий — скорость выполнения задачи, потому что каждый день отсутствия этой функции — это недополученая прибыль у клиента.

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

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

                                                                                                  Я не спорю, что есть ситуации, когда использование IDE по сравнению с редакторами экономит сотни и сотни человеко-часов. Но в моей практике такие ситуации исчезающе редки. Может это потому что не приходится иметь дело с Java.
                                                                                                    0
                                                                                                    Вопрос в практике. Я специализируюсь как раз на больших и очень больших проектах. И по моему скромному мнению без полноценной IDE в них делать нечего. Хотя текст кода я сам в виме пишу, да :).
                                                                                              +1
                                                                                              Ну вот вы сверху вниз добрались до странного метода, и понимаете, что вам его неплохо бы конкретно так поменять. Для того использования, по которому вы пришли, это решит вашу проблему. Вопрос: не поломает ли это изменение что-то еще, завязанное на этот метод?
                                                                                                0
                                                                                                Во-первых я буду смотреть по ситуации, во-вторых тот факт, что IDEA поменяет везде в коде сигнатуры метода не будет означать, что ничего нигде не сломано. Тут вас спасут только тесты.

                                                                                                Использую для таких вещей ack. search.cpan.org/~petdance/ack-2.12/ack

                                                                                                Если мне нужно будет рефакторить метод с названием типа toString, то понятное дело у меня будут боооольшие проблемы. Но неужели вы правда думаете, что если бы мне приходилось сталкиваться с такими проблемами, я бы не поменял окружение на более подходящее?
                                                                                                  +1
                                                                                                  Если мне нужно будет рефакторить метод с названием типа toString, то понятное дело у меня будут боооольшие проблемы. Но неужели вы правда думаете, что если бы мне приходилось сталкиваться с такими проблемами, я бы не поменял окружение на более подходящее?


                                                                                                  Ну вот, видите, даже вы согласились что ряд задач требует IDE, которые могут что-то, чего не может ack. А вот один из авторов erlang, заявление которого мы тут обсуждаем, утверждает что все тулзы за 40 лет не улучшились.
                                                                                                    0
                                                                                                    Ну так если не вдаваться в детали, то он прав. Как только в топовых средах разработки появился вменяемый intellisense для языков со статической типизацией, популярность начали набирать динамические языки, для которых качество автодополнения могло бы быть и лучше при том оверхеде, что дает тяжелая IDE.
                                                                                                      0
                                                                                                      Не вижу как он может быть прав, если он говорит «не улучшилось», а в топовых средах разработки «появился intellisense для языков со статической типизацией». Которые энтерпрайз мейнстрим C++/C#/Java и которых 40 лет назад не было. Ни языков, ни IDE.

                                                                                                      А что до динамических, см. выше мой скриншот от Visual Studio 2013 для Python. Все уже работает.
                                                                                                        +1
                                                                                                        Пример из текущего проекта на Symfony2. Есть куча классов объявленных как сервисы, причем маппинг имя класса <-> имя сервиса лежат в отдельном yaml файле.

                                                                                                        Экземпляры классов получаются конструкциями вида:

                                                                                                        // получить экземпляр SomeClass
                                                                                                        $x = $this->get('service.repository.someclass');

                                                                                                        Учитывая, что связь между строчкой 'service.repository.someclass' и классом SomeClass устанвливается через третий файл, который подгружается через 10 слоев абстракций, то сделать вменяемое автодополнение для методов $x не представляется возможным. Можно конечно лепить везде аннотацию var к каждой такой переменной, но не могу сказать, что мне нравится читать такой код, где логика прерывается комментариями, написанными для среды.
                                                                                                    +1
                                                                                                    Во-первых я буду смотреть по ситуации, во-вторых тот факт, что IDEA поменяет везде в коде сигнатуры метода не будет означать, что ничего нигде не сломано. Тут вас спасут только тесты.

                                                                                                    Я имею ввиду, что в подобной ситуации для начала неплохо бы посмотреть, где еще в проекте «вызывается конкретно этот метод».
                                                                                                +1
                                                                                                угу. только при чем тут Java, если статья конкретно про Erlang?

                                                                                                в этом цирке «Станый Метод» может быть запросто результатом чего-то в роде string:concat(X, Y), или того хуже. это совсем другой мир, где от AST толку чуть. распоследние тулзы пытаются даже код выполнять, но у и этого подхода есть принципиальные ограничения.
                                                                                                  0
                                                                                                  Потому что я прокомментировал и обсуждаю вот это высказывание одного из разработчиков erlang:
                                                                                                  «Тулы, которые у нас есть сейчас, ничем не лучше тех что были 40 лет назад.»

                                                                                                  Под тулзами там имеются в виду VIM и мейкфайлы. При чем тут они, когда статься про Erlang?
                                                                                            +1
                                                                                            К слову go to definition и find all references могут быть настроены в vim и emacs. Для языков поддерживающих ctags и gtags


                                                                                            Для чего-то сложнее hello world — не могут. Потому что с точки зрения ast языка, строчка «auto a = foo.create(); a.name = „bar“;» имеет в виду поле 'name' объекта, который создает «foo.create()». О том, что это за объект знает компилятор и, возможно, статический анализатор. ctags об этом знать не может. И, соответственно, «find all references» в режиме ctags мало отличается от grep, что на сложный проектах от мегабайта исходников чуть менее чем бесполезно.

                                                                                            А какая группа языков используется? И насколько плохи «менее сильные» разработчики? Каков объем проектов?


                                                                                            Я в основном на enterprise экзотике специализируюсь: C++, C#, Java. Что с рефакторингом у мейнстримовых php, python, ruby и js для веб страничек я не знаю, увы. Обычно проблем вызывают проекты от мегабайта исходников. Я еше ни разу не видел, чтобы команда запуталась в тысяче строк кода :). Менее сильные разработчики обычно плохи на уровне 50-60к белыми на руки по Москве. То есть действующий/недавний студент который прочел пару книжек, написал велосипед и, возможно, год работал единственным разработчиком в неайтишной компании. Такова суровая правда жизни — специалистов по 150к нанимать долго, дорого, сложно и плохо масштабируемо. Работаем с тем что есть.
                                                                                              +1
                                                                                              Спасибо, вы очень прояснили ситуацию. Я правильно понимаю, что схема работы такова, что масса таких «студентов» пишет бизнес-логику, а уже тимлиды постоянно это дело рефакторят и приводят в порядок?

                                                                                              Для чего-то сложнее hello world — не могут. Потому что с точки зрения ast языка, строчка «auto a = foo.create(); a.name = „bar“;» имеет в виду поле 'name' объекта, который создает «foo.create()». О том, что это за объект знает компилятор и, возможно, статический анализатор. ctags об этом знать не может. И, соответственно, «find all references» в режиме ctags мало отличается от grep, что на сложный проектах от мегабайта исходников чуть менее чем бесполезно.


                                                                                              Узнаю почерк сидящего в /pr
                                                                                                0
                                                                                                Ну сил на «преведение в порядок» у тимлидов в реальности не остается :). Скорее, стараются держать технический долг на уровне, потребном бизнесу. Чтобы продукт целиком не сгнил раньше, чем это предусмотрено. И чтобы расширение в ожидаемые стороны не всегда требовало переписывать с нуля. Где-то так.

                                                                                                Так что тулзы для работы с кодом очень потребны, да. Конкуренция, одним вимом и мейкфайлами уже обходиться тяжеловато.
                                                                                                  0
                                                                                                  Для описанной ситуации вы целиком правы — IDE тут правда необходима. И рядовых программистов оградит от ошибок и тимлидам сэкономит время на подчистку кода. Если для вас не составит труда выложить какой-то пример-другой кода, который был выдан программистом и который с ходу нуждается в рефакторинге? Только не синтетический, если можно, а из реального проекта, чтобы было понятно о чем мы спорим.
                                                                                                    0
                                                                                                    Батенька, ну где же я вам enterprise код найду, который был бы публичный? На публичные меня никто не приглашает :(. Все за что мне деньги платят во внутренних репозиториях лежит. И цитировать я оттуда не могу — потому что NDA.
                                                                                                      0
                                                                                                      Вот из последнего пример. Не самый крупный, но и немаленький джава-проект с кривой системой авторизации, которую нужно привести в порядок. В глубине этой системы лежит реализованный строками идентификатор доступа, который генерируется из имени класса, дергается по всей программе и так строками и пишется в базу постоянно. Работать сложно, потому что в программе тысячи методов, которые на вход принимают строку, и поди разберись, что это за строка. Для упрощения дальнейшей работы неплохо бы выпилить это безобразие и заменить нормальным классом, а в методы передавать не непонятную строку, а экземпляр класса с несколькими полями. Тут без толковой поддержки рефакторинга как без рук.
                                                                                            +2
                                                                                            Другое дело, что такая задача весьма специфична, и занимает примерно 1% времени от работы среднего программиста

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

                                                                                            А что вы в такой ситуации делаете: миритесь с тем, что название уже не соответствует, или делаете глобальный find/replace с ручным контролем, какие места переименовать, а какие пропустить?
                                                                                              0
                                                                                              Глобальный find/replace с ручным контролем. И это не так страшно как кажется, во всяком случае с emacs. Но к счастью делать это мне приходится не чаще раза в год. Если бы постоянно сталкивался с такой проблемой, то пересел бы на IDE.
                                                                                    0
                                                                                    Хочу кстати спросить у автора перевода. spiff, как сами то относитесь к сказанному к статье? Согласны по каким-то пунктам, по всем, статья опубликована ради дискуссии?
                                                                                      +9
                                                                                      Я согласен с тем, что никакие тулы не отменяют необходимости думать головой и понимать, что именно ты делаешь. Я как человек из мира системного программирования (в данный момент разработка компиляторов) пишу как раз 10-20 строк в день и вполне обхожусь Vim, Makefile и grep. В этом плане я Джо поддерживаю. С другой стороны у меня есть Java OSS проект c которым без супер-соврменной IDE работать почти невозможно. Я конечно, знаю там каждую строку и даже могу на коленке (в Notepad) написать какой-нибудь патч, но я предпочитаю использовать Intellij IDEA для этого.

                                                                                      Мне в словах Джо вот, что приглянулось. Последний абзац. У нас действительно проблема. Мы все говорим на разных языках. Да, 40 лет назад любой программист понимал любого другого с полуслова. Но сейчас — у нас уже куча специализаций, кланов если хотите. Я не говорю, что это плохо. Это прогресс, скорее всего. Но я за то, чтобы хоть как-то сохранить связи и иметь в наличии язык на котором мы сможем говорить. И я зык этот дожен быть не тулом а чем-то более глобальным. Я глубоко надеюсь, что то что называется Computer Science и есть этот самый универсальный язык. И его нужно стараться сохранять и учить независимо от того в какой области вы работаете — веб или системного программирования.
                                                                                        0
                                                                                        А это действительно проблема? Т.е., если встретятся два инженера, один из которых всю жизнь проектировал тракторы с отсутствием электроники, а второй — мобильные телефоны, как быстро и просто они смогут найти общий язык? Номинально все чертежи и схемы пишутся по стандартам, но реально, если окунуться в чужую область — сколько времени понадобится, что бы понять всю специфику, что бы начать говорить на одном язык? Ситуация такая сложилась наверняка не только у программистов.

                                                                                        Ну или как вариант, что ни вас, ни Джо верно не понял.
                                                                                          0
                                                                                          Ну ваш пример слегка вычурный. Это действительно два разных инженера (Electrical Engineering и Машиностроение?). Эти ребята разве что на языке математики и физики будут договариваться. Мой поинт в том, что формально мы все люди из одной сферы и занимаемся одним и тем-же — «при помощи текстовых файлов говорим компьютерам что делать ».
                                                                                      +13
                                                                                      Одни пишут 10 строк в день и уверенно двигаются к конечному продукту
                                                                                      Бла-бла-бла. 10 строк — одни лишь импорты, инклюды, дефайны и прочая нужная фигня. Пусть сам их руками пишет.
                                                                                      Я помню времена, когда программисты отлично понимали друг друга
                                                                                      Бла-бла-бла. Это он про те времена, когда не было стандартов языков, стандартов железа, на каждой машине стоял полностью свой вендорный набор софта, а индустрия ныла о том, как фигово готовить специалистов, когда это «специалист по XYZ-1020 фирмы ABC», ага.
                                                                                        0
                                                                                        Большую часть времени провожу в IDEA от JetBrains, тем не менее, я очень люблю vim, bash, make, awk, sed и пр. и слазить с этих инструментов пока желания нет.
                                                                                          +5
                                                                                          Я трачу 65% времени на то, чтобы разобраться почему не работает тот или иной тул. Каждый раз, появляются какие-то проблемы и мне постоянно приходится их исправлять.


                                                                                          Ну слава богу. А я думал, что то у меня руки кривые или интуиция работает не в ту сторону.
                                                                                            +7
                                                                                            Сейчас же, человек который ничего не видел кроме Java и Maven входит в ступор, когда ему присылают Rake-файл.


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

                                                                                              image
                                                                                                0
                                                                                                Распределение плюсов и минусов дает понимание того, что доля Java-программистов среди остальных очень велика.
                                                                                                  +4
                                                                                                  Вариант «я сморозил фигню» почему то никто не рассматривает никогда, просто общество плохое ))

                                                                                                  P.S. Я не минусовал. Толку то минусовать комментарии? Место они занимают, а до автора всё-равно ничего не дойдёт.
                                                                                                0
                                                                                                Кажется, товарищ Армстронг забыл, что тулы нужны не только для того, чтобы решать задачи, но и чтобы легко делиться плодами своего труда с другими. Ну и опять же, почему бы умному человеку не писать тулы, чтобы автоматизировать рутинные задачи и не повторять рутинные действия снова и снова?
                                                                                                  0
                                                                                                  Зачем? Так же можно похвастатся, какой ты офигенный, что неделями программил на перфокарты, а нынче «молодеж» вообще разбалованная.
                                                                                                  Хотя учить стоит имхо с консоли в том числе, потому что встречаю повсеместно например Android девов, которые не могут сбилдить программу с консоли и не знают, что такое maven/ant/gradle. В большинстве случаев мб это и не надо, ведь IDE автоматизирует процедуру построения, но бывают случаи, когда бы это знать не помешало бы.

                                                                                                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                                                Самое читаемое