Пользователь
0,0
рейтинг
6 сентября 2012 в 22:03

Администрирование → Unix как IDE: Введение перевод

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

Подобные средства есть для всех распространенных настольных ОС, включая Linux и BSD, и многие из них совершенно бесплатны, так что вряд ли имеет смысл ограничивать себя в Блокнотом Windows, nano или cat.

Однако, в среде поклонников Unix гуляет в разнообразных вариациях мем о том, что «Unix — это IDE», в том смысле, что средства, которыми разработчики располагают в терминале, легко реализуют основные возможности современных IDE. Вы можете соглашаться или отказываться признать Unix «IDE» в том самом смысле, что Eclipse или Microsoft Visual Studio. Так или иначе, вас скорее всего удивит, насколько законченную среду разработки может являть собой скромный Bash.


В каком смысле Unix — это IDE?


Смысл IDE состоит в том, чтобы объединить все инструменты общей концепцией интерфейса, и без лишних мучений научить их совместной работе. Это особенно важно для GUI-приложений, поскольку они обычно с большим трудом находят общий язык. Кроме возможности копипастить текст, у них нет других средств взаимодействия.

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

Отличная идея



Такой подход не остался уделом только лишь убеленных сединой ветеранов Unix; вокруг современных воплощений Vi и Emacs (Vim и GNU Emacs) образовались сообщества разработчиков, работающие над расширениями для любых видов работы с текстом. Для обоих редакторов есть плагины под любые программистские задачи, и ряд из них я назвал бы жизненно важными.

Мне кажется, что в конечном счете разработчики расширений стремятся превратить названные текстовые редакторы в настоящие IDE. Нередко можно встретить посты о том, что Vim или Emacs можно вообще не покидать в процессе работы.
Но, думается, впихивать в текстовый редактор несвойственные ему возможности не есть верный подход к проблеме. Bram Moolenaar, автор Vim, похоже, в значительной степени согласен со мной, если судить по :help design-not. Командная строка всегда доступна по Ctrl-Z, и ее зрелый, хорошо интегрированный внутри себя инструментарий по возможностям заткнет за пояс любой текстовый редактор.

О этой серии публикаций



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

  • Управление файлами и проектамиls, find, grep/ack, bash
  • Текстовый редактор и средства редактированияvim, awk, sort, column
  • Компилятор и/или интерпретаторgcc, perl
  • Средства сборкиmake
  • Отладчикgdb, valgrind, ltrace, lsof, pmap
  • Контроль версийdiff, patch, svn, git


О чем не буду говорить


Я не считаю, что IDE плохи; они великолепны, как раз поэтому я и пытаюсь утверждать, что Unix можно использовать аналогично, или по крайней мере думать о Unix в таком качестве. Я также не собираюсь утверждать, что Unix — всегда лучшее средство для задач программирования; вероятно, он гораздо лучше заточен для разработки на C, C++, Python или Shell, чем для таких мейнстримных языков, как Java или C#, особенно в части написания сложных GUI-приложений. Также я не собираюсь убеждать вас выбросить на свалку тяжко выстраданное знание Eclipse или Microsoft Visual Studio в пользу несколько эзотеричного мира командной строки. Я лишь хочу показать вам, чем мы занимаемся по ту сторону ограды.

Unix как IDE: Введение
Unix как IDE: Файлы
Unix как IDE: Работа с текстом
Unix как IDE: Компиляция
Перевод: Tom Ryder
Иван Демин @kamelopardus
карма
59,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Администрирование

Комментарии (71)

  • +11
    Подписываюсь на продолжение :)
  • 0
    почитаю с удовольствием.
    Мне кажется, что make — староватый способ для сборки. Ant выглядит значительно сильнее.
    • +5
      Ant тоже уже староват по сравнению с Rake, SCons и Rebar.
      • +1
        Я только про Rake раньше слышал, но мне неохота Руби учить. Rebar — на Эрланге, мы не осилим. SCons — интересно, надо будет ознакомиться (Питон я люблю).
        • +5
          Если вы знаете бейсик, то сможете программировать на Ruby. Только никому не говорите — это тайна. Тссс… :)
        • +2
          >SCons — интересно, надо будет ознакомиться (Питон я люблю).
          лучше смотрите на Waf тогда. SCons — штука довольно убогая и тормозная.
          • 0
            Скунс действительно трудно кому-либо рекомендовать. Помню, как, пытаясь побороть очередной баг в каком-то SConstruct-файле, наткнулся на забавную памятку.
            • 0
              Странно, что он используется при сборке V8 и по-моему, Chrome.
              • +1
                Думаю, дело в том, что SCons появился раньше CMake (а одна из фишек обоих — нативная поддержка *nix, Windows, Mac OS X; их в основном из-за этого любят). Кто-то сумел соскочить, кто-то остался: «ну да, подчас криво бывает, но как-то работает ведь, чего трогать». :-)
              • 0
                Если не ошибаюсь, в Хроме используется самописный GYP — Generate Your Project.
          • 0
            спасибо за совет. Благодаря вам я понял, что всё фигня — и SCons, и Waf. Последнего вообще нет в репозиториях Убунты, а кроме того у них нет удобной интеграции с VCS. Нет смысла рыпаться — только ant, make и bash.
            • +1
              Потому что waf не нужно устанавливать, его вместе с дистрибутивом в исходики класть надо, ибо у него нет зависимостей (ну акромя питона канеш).

              SCons и Waf писались одновременно для KDE. Но KDE все же выбрал CMake на тот момент, по ряду причин. Сейчас waf не особо развивается. Но он нереально быстр, очень умён и не очень прост в освоении.

              SCons очень медленный. Очень.

              Вообще почитать wafbook стоит любому кто выбирает систему сборки. Там популярно разжевано в каких случаях и почему waf быстрее/лучше.
              • –1
                для сборки с помощью Waf необходимо написать почти полноценный Питон-скрипт (ну да, там есть парочка дополнительных библиотек, рещающих очень мелкие задачи). Мне неинтересно писать систему сборки для себя почти с нуля. Например, для изучение Анта мне не пришлось учить Яву. Так что для меня не годится, каким бы сверхбыстрым он ни был.
                • +4
                  >для сборки с помощью Waf необходимо написать почти полноценный Питон-скрипт
                  для сборки с помощью Ant необходимо написать почти полноценный ant xml-файл

                  >(ну да, там есть парочка дополнительных библиотек, рещающих очень мелкие задачи)
                  эта «парочка дополнительных библиотек» решает гораздо больше проблем чем те что покрывает ant ;)

                  >Мне неинтересно писать систему сборки для себя почти с нуля
                  В отличии от Ant'а, waf конечно позволяет сделать и такое. Достаточно взять исходники waf'а и при компиляции указать какие скрипты включить при сборке, очень полезная вещь для генерации кастом билдеров.
                  Мы используем эту технику для создания билдеров, которые на автомате распознают как собирать проекты без каких-либо настроек, главное чтоб всё в проекте лежало в правильных директориях итп(для простых проектов).

                  >Например, для изучение Анта мне не пришлось учить Яву
                  Для изучения ant'а пришлось изучать их внутренний язык из xml-разметки, с которым разобраться ничуть не проще чем с python'ом.

                  ant
                  <if>
                   <equals arg1="${foo}" arg2="bar" />
                   <then>
                     <echo message="foo is bar" />
                   </then>
                   <else>
                     <echo message="foo is not bar" />
                   </else>
                  </if>
                  


                  waf
                  if foo == 'bar':
                    print 'foo is bar'
                  else:
                    print 'foo is not bar'
                  


                  А теперь представьте что будет когда нужно сделать что-либо посложнее ;)
    • +4
      Да, Ant лучшее решение для сборки apache или vim. А еще лучше freebsd port переписать с использованием Ant.

      Кстати, те парни, что пытались перенести все системные скрипты на php в Linux не твои знакомые?
      • 0
        Ant — лучше для сборки МОЕГО проекта, написанного на РНР и Флексе
        • –3
          извини, о какой «сборке» идёт речь в случае php?
          • 0
            вынуть из СВНа несколько проектов, разложить их.
            Когда в проекте несколько языков, как Экшн Скрипт у нас, то удобно всё вместе делать одной системой сборки.
          • +2
            Ещё возможные действия:
            — минификация/обфускация клиентского кода (html/css/js)
            — компиляция скриптов на языках вроде HAML, LESS, CofeeScript
            — слияние нескольких css/js в один
            — генерация phar и/или установщика
            • 0
              Asset pipeline?
              Так вроде Yii уже умеет это, нет?
    • +1
      Вместо make для простых проектов хорошо подходит чистый bash — напишешь маленький скриптик, он тебе всё и соберёт. Причём, кроме сборки сможет много чего ещё сделать.
      • +2
        Make всё-таки удобнее засчёт декларативности своей. Да и как Вы зависимости в шелл-скрипте укажете, например?
        • –1
          Не спорю, make для больший проектов удобнее, но зато в shell'е можно описать любую хитрую логику сборки, а зависимости легко решаются написанием пары функций.
          • +1
            Make удобнее даже для маленьких проектов, потому как это инструмент, специально для этого придуманный. И там можно описать любую хитрую логику сборки. И не надо ничего велосипедить, чтобы указать, что A зависит от B.
            • 0
              Я не пытаюсь оспорить могущество великого make'а! =)

              Просто иногда скриптики действительно удобнее. К примеру, делал я разнообразные тестовые программки, для которых нужен был только один .c файл с main'ом, а на выходе — кучка бинарников. Так вот скрипт мой не только собирал все .c файлы в запускаемые бинарники, но и генерировал новые .c-шники по нужным запросам, открывал редактор и при успешной сборке сразу запускал результат. Пример можно на гитхабе посмотреть: это сишная музыка, для вывода нужен sox.
    • 0
      make очень хорош для простых проектов. Для чего-то более-менее сложного можно использовать более высокоуровневые вещи, которые генерят те же Makefil'ы, например CMake.
    • 0
      Если говорить о java, то maven более современное средство сборки, чем Ant. Мне лично, после мавена, как-то очень некомфортно описывать сборку на анте. Да и автоматическое выкачивание всех депенденсей — это намного удобнее, чем качать ручками и складировать в папку.
  • 0
    Жду с нетерпением. Однажды была попытка использовать bash+Vim+django для разработки, но после двух дней пересел на Eclipse. Всё устраивало, кроме одного — автодополнения.
    • +2
      Та же история с вимом — автодополнение работает медленно, и настраивать его умную работу долго и сложно — купил PHPStorm. В современной IDE много инструментов, которые нетривиально реализуются в виме или емаксе. :(
      • +1
        Таже ситуация. Был разве что взят pycharm. До этого, отлично справлялся Netbeans, пока в неи не запилили python. Да и pycharm оказался удобней )
    • 0
      Даже когда впервые знакомился с вимом, не приходилось испытывать проблем со стандартным автодополнением любого слова по Ctrl-P… а для его кастомизации есть плагины. Что вас в нем не устроило?
      • +2
        Он не проводит синтаксического анализа исходников, дополняет код также как простой текст, не ограничивая варианты только допустимыми с одной стороны, но, с другой, ограничивая их, максимум, одним каталогом (то есть если используется в проекте какая-то библиотека из /usr, то vim её сущности не «подцепит» автоматом).
  • –3
    рассматривать vim+awk+grep как замена IDE — изврат. хотел бы я посмотреть на джавистов пишущих в vim`е
    • +9
      Смотрите, вот он он. Хотя я давно на джаве не пишу, но когда писал на Java — делал это в vim под убунтой. Причем писал софт под малюсенькие SoC. Еще один мой коллега писал видеосервера на джаве под emacs, правда на маке. Но Мак — это тоже юникс по большому счету.
      Так что не важно какой язык, главное чтоб инструмент был удобен разработчику. На любом языке, написание кода — это написание текста, можно с помощью echo писать даже.
      • +2
        Я с вами не спорю, что текст можно набрать в любом редакторе. Но зачем отказываться от удобства использования IDE.
        • 0
          У меня сейчас стоит именно такая задача. Есть Raspberry Pi. И есть необходимость разработки непосредственно на на RPi java-программы.
          • 0
            1. Это частный случай.
            2. IDE на настольной машине и sshfs к Raspberry Pi
            • –3
              Зачем мне:
              1) замусоривать настольную машину ненужным на ней софтом?
              2) таскать с собой кроме RPi еще и настольную машину?

              Когда мне нужно было разрабатывать програмы для Nokia N900, мне оказалось гораздо удобнее вести разработку непосредственно на N900 вместо того, чтобы выстраивать вавилоны на ноуте.
  • –2
    Все это отлично, но отсутствие автокомплита не дает воспринимать шелл как серьезное место для разработки, конечно можно привыкнуть, но зачем?
    • 0
      Для vim и emacs есть плагины для автокомплита, рефакторинга и прочих радостей IDE.
      • +1
        Не нужно пудрить мозги.

        Все это жалкая пародия от автокомплита больших, я пробовал и когда дело касается обращений к методам вложенных обьектов и вариаций все ужасно. Да и в большинстве этих поделок автоматически даже не раскрывается список методов, какой же это АВТОкомплит?

        Можно доказывать сколько угодно, но в нормальной IDE можно сделать управление как в Vim, Emacs, а вот из этих редакторов IDE полноценную получить нельзя, точнее можно, но тогда нужно брать и писать руками, а писать там дофига, да и зачем если уже все написано у больших.
        • –2
          не осилили?
          • +2
            Не осилил что? Написать свое решение для Vim? Мне это просто не интересно, особенно когда все уже сделали в Jetbrains.

            Vim'ом пользуюсь исключительно как наколенным редактором.
            • –1
              Не пользуюсь автокомплитом — лично мне данная фича больше мешает, чем помогает.
              • +1
                Некоторым и блокнота хватает, а все остальное лишнее. В этой ветке идет обсуждение взрослой разработки, так вот хранить в памяти инетрфейсы к каждому классу не просто глупо, а очень глупо, особенно когда это можно перекинуть на плечи IDE, исключив при этом еще и пласт ошибок.

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

                А еще лучше подкреплять свои минусы ссылочками к плагинам и сборкам, а то как то ваши минусы в карму звучат не очень убедительно.
                • +2
                  У каждого свой подход к разработке. Если бы я, подобно многим коллегам, могла бы «творить» только при наличии мягкого кресла, 4 ядер в процессоре и минимум двух 20+" мониторов, я бы успевала значительно меньше, чем используя для разработки (вполне «взрослой») пусть слабые и менее широкоэкранные — зато гораздо более легкие и компактные девайсы, позволяющие работать тогда, когда есть желание, а не тогда, когда создадутся условия.

                  Именно поэтому мне интересна тема организации удобной разработки средствами Linux, и потому я читаю данную тему. Вам же это кажется неудобным и бессмысленным — но Вы почему-то тоже в этой теме. Я не против, но конструктив по данной теме мне был бы гораздо интересней холивара.
                  • +4
                    Читать подобные темы вполне можно и считая IDE идеалом, а «Unix как IDE» вынужденным, но иногда неизбежным злом. Имхо, главное преимущество разработки в CLI/TUI — крайне низкие системные требования к хосту и каналам связи, разработку можно вести удаленно на дешёвом VDS с практически любого современного и не очень девайса, установив максимум одну легковесную софтину. Удобным лично я не считаю, но иногда возникает необходимость работать и в неудобных условиях.
  • 0
    Компилятор и/или интерпретатор — gcc, perl
    Очень даже может быть, что если писать исключительно на этих языках, то перечисленных инструментов хватит. Не уверен насчет Perl, но С, как язык со статической типизацией, должен относительно легко поддаваться всякому там статическому анализу и линту.

    А так вообще собирать/компилировать/линтить проект можно и не выходя из vim'а (emacs'а). Esc :!make
    • 0
      У vim’а есть :make; посмотрите её описание на предмет, чем оно лучше :!make.
  • +1
    Не так давно нашёл на слайдшаре неплохую презентацию на эту же тему: www.slideshare.net/tkramar/unix-is-my-ide
  • +7
    У меня вопрос: насколько реально в такой «IDE» реализовать автокомплит и продвинутый анализ синтаксиса (продвинутый — в смысле с учетом подключенных библиотек проекта, и библиотек, которые подключены в них, и т.д.)?
    • +2
      Однако, в убунтовом bashe есть синтаксический автокомплит.
      Аргументы для git add / git remove и всё такое…
      • 0
        Собственно, для любого баша автокомплит команд можно прикрутить. Но guess_who задал другой вопрос: есть ли автокомплит для языков программирования. И к башу как таковому этот вопрос не относится: это к vim/emacs и прочему, для которых, кстати, есть соответствующие плагины.
        • 0
          К vim и emacs оно действительно прикручивается, причом в корне именно юниксовыми средствами («файлами и потоками»)

          Но в вопросе непонятно, какой именно «такой» «IDE» имелся ввиду.
          Если «чисто юникс» — то это какраз шел.

          А с другой стороны, синтаксис sed тьюринг-полный.
          На sed можно написать и калькулятор, и шахматы, и квэйк, и эмулятор андроида.
          Но лучше этого не делать.
          • 0
            В посте сказано:
            Текстовый редактор и средства редактирования — vim, awk, sort, column

            Собственно, vim — это тоже часть юникса.
            • +1
              а юникс — часть emacs
              • 0
                Причем, самая простая его часть.
      • +2
        Упс, не того гесс-ху упомянул, вопрошал ведь guessss_who =)
      • +1
        Кстати, автокомплит для git уступает таковому для hg.
    • +3
      Присоединяюсь к вопросу. В разработке на C/C++, когда куча хедеров, делать автокомплит только по словам в текущем файле недостаточно. Приходится в случае чего лазить в другие файлы(хедеры). Память-памятью, а помнить всё сложно, особенно когда чужой проект или свой необходимо доработать даже после месяца перерыва. В VS с установленным Visual Assist автодополнение работает шикарно.
      • 0
        Для C/C++ возможно скоро всё будет :) Смотрите Clang Service
    • 0
      Для ruby более чем реально.
      В руби все объект, у каждого объекта есть метод methods, который возвращает список доступных объекту методов. Т.о. автокомплит встроен в среду.
      Что касается Ruby on Rails, то ситуация аналогичная. Использовать встроенный в фреймворк автокомплит в IDE(если ее рассматривать как надстройку над фреймворком) не должно составить труда

      Для примера
      >> User.first.id_ #тут я кликнул по табу два раза
      User.first.id_before_type_cast
      User.first.id_changed?
      User.first.id_constraint?
      User.first.id_partition
      User.first.id_was               
      User.first.id_change
      User.first.id_constraint
      User.first.id_left
      User.first.id_right
      User.first.id_will_change!
      


      Завтра-послезавтра, кто-нибудь сядет и напишет автокомплит для sublime text 2

      Другой пример:

      1.9.3-p194 :204 > Point.instance_method(:image).source_location
       => ["/home/anton/work/tradein/app/models/point.rb", 18] 
      
      
      • 0
        Очень интересно.

        А вы не в курсе, как насчет Python/Django?
        • 0
          Нет, а тот которого я знаю, который знает, в отъезде. :(
  • +4
    Супер! Это очень интересно, но почему же не рассказан хотя бы первый пункт? Жду продолжения с нетерпением!
  • +1
    Тут вроде пара перцев (Керниган и Пайк) что то подобное уже написали "UNIX — универсальная среда программирования".
  • +1
    Добавьте cmake в средства сборки и получите набор инструментов, способный удовлетворить потребности всех — и любителей различный IDE и тех, кто пишет в VIM + console.
  • +3
    Даешь «Far как IDE» или даже «Windows как IDE»! (да, это легкий сарказм)

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

    Но я готов с размаху ударить башмаком тех, кто позволяет себе говорить, что «Unix — 'то IDE» или что «Unix — это как IDE».
    Мне не нравится подобная подмена понятий: говоря в статье про Unix имеют в виду набор несвязанных между собой инструментов (с какого перепугу, например, svn и vim отнесли к «Unix»'у?), единственным связующим звеном между которыми является shell (в частности, bash).
    С тем же успехом все то же самое можно делать в рамках виндового cmd.exe.

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

    Vim, Emacs, Notepad++, Sublime Text — это текстовые редакторы (даже очень и очень мощные), которые могут превратиться IDE, если будет достаточно плагинов, да и то с натяжкой.

    Unix (GNU/Linux, *BSD, etc) — это операционные системы, где есть очень мощные shell'ы и стройная концепция взаимодействия простых консольных программок, благодаря чему можно нормально заниматься разработкой софта, но которые не дают представления какого-то пректа, как единого целого: левая рука не знает, что делает правая, ls вряд ли понимает, что какие-то файлы — это просто результат компиляции, а другие — исходники, а make же не в курсе, что вы только что разделили в Vim'e один большой модуль на несколько маленьких, да еще по папкам разделили и т.д., а сам же Vim вряд ли сможет переименовать имя одного метода класса, которое еще и повторяется у других классов.

    А вот Visual Studio, Eclipse, Intellij Idea и даже C++ Builder — это IDE. Они знают, что из себя представляет проект. Учитывают контексты, в которых написан код (классы, области видимости переменных, пэкеджи и пр.).
    Позволяют быстро и эффективно собирать, рефакторить, редактировать, запускать проект без необходимости личного обращения к другим программам.
    • –3
      Если вы хоть когда-нибудь говорите фразу «да, это сарказм», то вы, извините, идиот)

      По существу: если вы такой любитель придираться к словам, то IDE — это набор средств для разработки. Абсолютно неважно 1 это программа или 1000.

      Ваша IDE тоже использует svn, с какого перепугу?

      Лучшие программисты которых я видел, которые пишут самый адекватный код — из тех что я знаю, делают это в мощных текстовых редакторах. Будь-то jedit или vim или emacs или новомодный sublime. Я до глубины души считаю что IDE — это зло. Наша голова способна вмещать гигантское кол-во информации. И помнить классы/методы/параметры ко всему и вся — можно. Постепенно привыкаешь запоминать это с первого раза. Потом — привыкаешь писать ТАК, чтобы в следующий раз даже вспоминать НЕ НАДО было, так, что в следующий раз ты при использовании функции легко вписываешь те же параметры, как если бы писал функцию сейчас. Код становится куда проще для понимания при первом чтении. Рефакторинг становится проще и адекватнее. Даже баги становится проще чинить — потому что когда происходит хрень, ты уже *помнишь всё*. Не надо никуда лезть смотреть. Ты сразу предполагаешь что могло пойти не так. Для этого даже не нужно смотреть никуда — ты можешь такие проблемы решать *по телефону*. И вот это — дорогого стоит. А быть привязанным к IDE и даже никогда не набирать очень_вот_блин_длинную_функцию руками, и, как следствие, вообще со временем забыть какое окончание в названии у этой супердлинной функции — очень сочувствую я таким разработчикам.

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

      Если рассуждать так же как и я — то фраза «Unix как IDE» вполне адекватна. Я бы правда «как» заменил на «вместо».

      Впрочем, когда то разработчики были двух каст — «натянутые» и те, кто настолько сильно любит это ремесло, что посветил ему такое коллосальное кол-во времени, что в моём опусе видит смысла больше, чем кажется. Первая каста — это как преподаватели информатики. Которые узнали что-то одно, а больше и не надо. Так вот сейчас спустя десяток лет эти две касты остались, но стали мизерными по сравнению с третьей, новой: программист-обычный. И «обычных» настолько много, что работа у разработчиков IDE будет всегда =).

      Обидно только, разработчиков хороших теперь найти в 100500 раз сложнее стало =(
      • +3
        Если честно, я тоже могу многое рассказать про людей, которые называют других идиотами.

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

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

        Из личного опыта скажу: я писал программки на Java, пользуясь Vim'ом и вызывая компилятор из командной строки. Потом, по мере погружения в Vim и по мере надобности, он обрастал плагинами для автодополнений, разработки на Java, автоматизации тестов и пр.
        Но когда я попал на свою первую работу и столкнулся с огромным code-base'ом, то программировать в Vim'е становилось все труднее и труднее.
        В итоге я начал переходить на IntelliJ Idea и не пожалел, потому что это ускорило разработку в разы, т.к. теперь не надо было самому искать использования тех или иных методов, а также пытаться понять является ли класс Foo в коде из пакета foo.bar или foo.baz — IDE помогал сразу найти то, что нужно, отрефакторить что-либо, без необходимости тратить лишнее время на самостоятельные поиски юзов итд.

        Ну и в конце, еще раз КРАТКО напишу основной посыл своего исходного комментария:
        ДА, умение понимать и использовать оригинальные Unix'овые утилиты и программы для разработки — это хорошо, правильно и действительно работает.
        НО НЕТ, это не то же самое, что полноценное IDE.
        ТЕМ НЕ МЕНЕЕ, при должных навыках можно быть Гуру-программистом, даже просто используя hex-редактор, создавая сразу бинарный код.
  • +2
    Автор, у вас отличный слог, пишите дальше. Только жаль, что не включили хоть кусочек конкретики в первый пост. А тема интересная и, надеюсь, обойдётся без холиваров ;)

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