Comments 71
Подписываюсь на продолжение :)
почитаю с удовольствием.
Мне кажется, что make — староватый способ для сборки. Ant выглядит значительно сильнее.
Мне кажется, что make — староватый способ для сборки. Ant выглядит значительно сильнее.
Ant тоже уже староват по сравнению с Rake, SCons и Rebar.
Я только про Rake раньше слышал, но мне неохота Руби учить. Rebar — на Эрланге, мы не осилим. SCons — интересно, надо будет ознакомиться (Питон я люблю).
Если вы знаете бейсик, то сможете программировать на Ruby. Только никому не говорите — это тайна. Тссс… :)
>SCons — интересно, надо будет ознакомиться (Питон я люблю).
лучше смотрите на Waf тогда. SCons — штука довольно убогая и тормозная.
лучше смотрите на Waf тогда. SCons — штука довольно убогая и тормозная.
Скунс действительно трудно кому-либо рекомендовать. Помню, как, пытаясь побороть очередной баг в каком-то
SConstruct-файле, наткнулся на забавную памятку.Странно, что он используется при сборке V8 и по-моему, Chrome.
Думаю, дело в том, что SCons появился раньше CMake (а одна из фишек обоих — нативная поддержка *nix, Windows, Mac OS X; их в основном из-за этого любят). Кто-то сумел соскочить, кто-то остался: «ну да, подчас криво бывает, но как-то работает ведь, чего трогать». :-)
Если не ошибаюсь, в Хроме используется самописный GYP — Generate Your Project.
спасибо за совет. Благодаря вам я понял, что всё фигня — и SCons, и Waf. Последнего вообще нет в репозиториях Убунты, а кроме того у них нет удобной интеграции с VCS. Нет смысла рыпаться — только ant, make и bash.
Потому что waf не нужно устанавливать, его вместе с дистрибутивом в исходики класть надо, ибо у него нет зависимостей (ну акромя питона канеш).
SCons и Waf писались одновременно для KDE. Но KDE все же выбрал CMake на тот момент, по ряду причин. Сейчас waf не особо развивается. Но он нереально быстр, очень умён и не очень прост в освоении.
SCons очень медленный. Очень.
Вообще почитать wafbook стоит любому кто выбирает систему сборки. Там популярно разжевано в каких случаях и почему waf быстрее/лучше.
SCons и Waf писались одновременно для KDE. Но KDE все же выбрал CMake на тот момент, по ряду причин. Сейчас waf не особо развивается. Но он нереально быстр, очень умён и не очень прост в освоении.
SCons очень медленный. Очень.
Вообще почитать wafbook стоит любому кто выбирает систему сборки. Там популярно разжевано в каких случаях и почему waf быстрее/лучше.
для сборки с помощью Waf необходимо написать почти полноценный Питон-скрипт (ну да, там есть парочка дополнительных библиотек, рещающих очень мелкие задачи). Мне неинтересно писать систему сборки для себя почти с нуля. Например, для изучение Анта мне не пришлось учить Яву. Так что для меня не годится, каким бы сверхбыстрым он ни был.
>для сборки с помощью Waf необходимо написать почти полноценный Питон-скрипт
для сборки с помощью Ant необходимо написать почти полноценный ant xml-файл
>(ну да, там есть парочка дополнительных библиотек, рещающих очень мелкие задачи)
эта «парочка дополнительных библиотек» решает гораздо больше проблем чем те что покрывает ant ;)
>Мне неинтересно писать систему сборки для себя почти с нуля
В отличии от Ant'а, waf конечно позволяет сделать и такое. Достаточно взять исходники waf'а и при компиляции указать какие скрипты включить при сборке, очень полезная вещь для генерации кастом билдеров.
Мы используем эту технику для создания билдеров, которые на автомате распознают как собирать проекты без каких-либо настроек, главное чтоб всё в проекте лежало в правильных директориях итп(для простых проектов).
>Например, для изучение Анта мне не пришлось учить Яву
Для изучения ant'а пришлось изучать их внутренний язык из xml-разметки, с которым разобраться ничуть не проще чем с python'ом.
ant
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'
А теперь представьте что будет когда нужно сделать что-либо посложнее ;)
Да, Ant лучшее решение для сборки apache или vim. А еще лучше freebsd port переписать с использованием Ant.
Кстати, те парни, что пытались перенести все системные скрипты на php в Linux не твои знакомые?
Кстати, те парни, что пытались перенести все системные скрипты на php в Linux не твои знакомые?
Ant — лучше для сборки МОЕГО проекта, написанного на РНР и Флексе
извини, о какой «сборке» идёт речь в случае php?
вынуть из СВНа несколько проектов, разложить их.
Когда в проекте несколько языков, как Экшн Скрипт у нас, то удобно всё вместе делать одной системой сборки.
Когда в проекте несколько языков, как Экшн Скрипт у нас, то удобно всё вместе делать одной системой сборки.
Ещё возможные действия:
— минификация/обфускация клиентского кода (html/css/js)
— компиляция скриптов на языках вроде HAML, LESS, CofeeScript
— слияние нескольких css/js в один
— генерация phar и/или установщика
— минификация/обфускация клиентского кода (html/css/js)
— компиляция скриптов на языках вроде HAML, LESS, CofeeScript
— слияние нескольких css/js в один
— генерация phar и/или установщика
Вместо make для простых проектов хорошо подходит чистый bash — напишешь маленький скриптик, он тебе всё и соберёт. Причём, кроме сборки сможет много чего ещё сделать.
Make всё-таки удобнее засчёт декларативности своей. Да и как Вы зависимости в шелл-скрипте укажете, например?
Не спорю, make для больший проектов удобнее, но зато в shell'е можно описать любую хитрую логику сборки, а зависимости легко решаются написанием пары функций.
Make удобнее даже для маленьких проектов, потому как это инструмент, специально для этого придуманный. И там можно описать любую хитрую логику сборки. И не надо ничего велосипедить, чтобы указать, что A зависит от B.
Я не пытаюсь оспорить могущество великого make'а! =)
Просто иногда скриптики действительно удобнее. К примеру, делал я разнообразные тестовые программки, для которых нужен был только один .c файл с main'ом, а на выходе — кучка бинарников. Так вот скрипт мой не только собирал все .c файлы в запускаемые бинарники, но и генерировал новые .c-шники по нужным запросам, открывал редактор и при успешной сборке сразу запускал результат. Пример можно на гитхабе посмотреть: это сишная музыка, для вывода нужен sox.
Просто иногда скриптики действительно удобнее. К примеру, делал я разнообразные тестовые программки, для которых нужен был только один .c файл с main'ом, а на выходе — кучка бинарников. Так вот скрипт мой не только собирал все .c файлы в запускаемые бинарники, но и генерировал новые .c-шники по нужным запросам, открывал редактор и при успешной сборке сразу запускал результат. Пример можно на гитхабе посмотреть: это сишная музыка, для вывода нужен sox.
make очень хорош для простых проектов. Для чего-то более-менее сложного можно использовать более высокоуровневые вещи, которые генерят те же Makefil'ы, например CMake.
Если говорить о java, то maven более современное средство сборки, чем Ant. Мне лично, после мавена, как-то очень некомфортно описывать сборку на анте. Да и автоматическое выкачивание всех депенденсей — это намного удобнее, чем качать ручками и складировать в папку.
Жду с нетерпением. Однажды была попытка использовать bash+Vim+django для разработки, но после двух дней пересел на Eclipse. Всё устраивало, кроме одного — автодополнения.
Та же история с вимом — автодополнение работает медленно, и настраивать его умную работу долго и сложно — купил PHPStorm. В современной IDE много инструментов, которые нетривиально реализуются в виме или емаксе. :(
Даже когда впервые знакомился с вимом, не приходилось испытывать проблем со стандартным автодополнением любого слова по Ctrl-P… а для его кастомизации есть плагины. Что вас в нем не устроило?
Он не проводит синтаксического анализа исходников, дополняет код также как простой текст, не ограничивая варианты только допустимыми с одной стороны, но, с другой, ограничивая их, максимум, одним каталогом (то есть если используется в проекте какая-то библиотека из /usr, то vim её сущности не «подцепит» автоматом).
рассматривать vim+awk+grep как замена IDE — изврат. хотел бы я посмотреть на джавистов пишущих в vim`е
Смотрите, вот он он. Хотя я давно на джаве не пишу, но когда писал на Java — делал это в vim под убунтой. Причем писал софт под малюсенькие SoC. Еще один мой коллега писал видеосервера на джаве под emacs, правда на маке. Но Мак — это тоже юникс по большому счету.
Так что не важно какой язык, главное чтоб инструмент был удобен разработчику. На любом языке, написание кода — это написание текста, можно с помощью echo писать даже.
Так что не важно какой язык, главное чтоб инструмент был удобен разработчику. На любом языке, написание кода — это написание текста, можно с помощью echo писать даже.
Я с вами не спорю, что текст можно набрать в любом редакторе. Но зачем отказываться от удобства использования IDE.
У меня сейчас стоит именно такая задача. Есть Raspberry Pi. И есть необходимость разработки непосредственно на на RPi java-программы.
1. Это частный случай.
2. IDE на настольной машине и sshfs к Raspberry Pi
2. IDE на настольной машине и sshfs к Raspberry Pi
Зачем мне:
1) замусоривать настольную машину ненужным на ней софтом?
2) таскать с собой кроме RPi еще и настольную машину?
Когда мне нужно было разрабатывать програмы для Nokia N900, мне оказалось гораздо удобнее вести разработку непосредственно на N900 вместо того, чтобы выстраивать вавилоны на ноуте.
1) замусоривать настольную машину ненужным на ней софтом?
2) таскать с собой кроме RPi еще и настольную машину?
Когда мне нужно было разрабатывать програмы для Nokia N900, мне оказалось гораздо удобнее вести разработку непосредственно на N900 вместо того, чтобы выстраивать вавилоны на ноуте.
UFO just landed and posted this here
Для vim и emacs есть плагины для автокомплита, рефакторинга и прочих радостей IDE.
UFO just landed and posted this here
не осилили?
UFO just landed and posted this here
Не пользуюсь автокомплитом — лично мне данная фича больше мешает, чем помогает.
UFO just landed and posted this here
У каждого свой подход к разработке. Если бы я, подобно многим коллегам, могла бы «творить» только при наличии мягкого кресла, 4 ядер в процессоре и минимум двух 20+" мониторов, я бы успевала значительно меньше, чем используя для разработки (вполне «взрослой») пусть слабые и менее широкоэкранные — зато гораздо более легкие и компактные девайсы, позволяющие работать тогда, когда есть желание, а не тогда, когда создадутся условия.
Именно поэтому мне интересна тема организации удобной разработки средствами Linux, и потому я читаю данную тему. Вам же это кажется неудобным и бессмысленным — но Вы почему-то тоже в этой теме. Я не против, но конструктив по данной теме мне был бы гораздо интересней холивара.
Именно поэтому мне интересна тема организации удобной разработки средствами Linux, и потому я читаю данную тему. Вам же это кажется неудобным и бессмысленным — но Вы почему-то тоже в этой теме. Я не против, но конструктив по данной теме мне был бы гораздо интересней холивара.
Читать подобные темы вполне можно и считая IDE идеалом, а «Unix как IDE» вынужденным, но иногда неизбежным злом. Имхо, главное преимущество разработки в CLI/TUI — крайне низкие системные требования к хосту и каналам связи, разработку можно вести удаленно на дешёвом VDS с практически любого современного и не очень девайса, установив максимум одну легковесную софтину. Удобным лично я не считаю, но иногда возникает необходимость работать и в неудобных условиях.
Компилятор и/или интерпретатор — gcc, perlОчень даже может быть, что если писать исключительно на этих языках, то перечисленных инструментов хватит. Не уверен насчет Perl, но С, как язык со статической типизацией, должен относительно легко поддаваться всякому там статическому анализу и линту.
А так вообще собирать/компилировать/линтить проект можно и не выходя из vim'а (emacs'а).
Esc :!make 
Не так давно нашёл на слайдшаре неплохую презентацию на эту же тему: www.slideshare.net/tkramar/unix-is-my-ide
UFO just landed and posted this here
Однако, в убунтовом bashe есть синтаксический автокомплит.
Аргументы для git add / git remove и всё такое…
Аргументы для git add / git remove и всё такое…
Собственно, для любого баша автокомплит команд можно прикрутить. Но guess_who задал другой вопрос: есть ли автокомплит для языков программирования. И к башу как таковому этот вопрос не относится: это к vim/emacs и прочему, для которых, кстати, есть соответствующие плагины.
К vim и emacs оно действительно прикручивается, причом в корне именно юниксовыми средствами («файлами и потоками»)
Но в вопросе непонятно, какой именно «такой» «IDE» имелся ввиду.
Если «чисто юникс» — то это какраз шел.
А с другой стороны, синтаксис sed тьюринг-полный.
На sed можно написать и калькулятор, и шахматы, и квэйк, и эмулятор андроида.
Но лучше этого не делать.
Но в вопросе непонятно, какой именно «такой» «IDE» имелся ввиду.
Если «чисто юникс» — то это какраз шел.
А с другой стороны, синтаксис sed тьюринг-полный.
На sed можно написать и калькулятор, и шахматы, и квэйк, и эмулятор андроида.
Но лучше этого не делать.
Упс, не того гесс-ху упомянул, вопрошал ведь guessss_who =)
Кстати, автокомплит для git уступает таковому для hg.
Присоединяюсь к вопросу. В разработке на C/C++, когда куча хедеров, делать автокомплит только по словам в текущем файле недостаточно. Приходится в случае чего лазить в другие файлы(хедеры). Память-памятью, а помнить всё сложно, особенно когда чужой проект или свой необходимо доработать даже после месяца перерыва. В VS с установленным Visual Assist автодополнение работает шикарно.
Для C/C++ возможно скоро всё будет :) Смотрите Clang Service
Для ruby более чем реально.
В руби все объект, у каждого объекта есть метод methods, который возвращает список доступных объекту методов. Т.о. автокомплит встроен в среду.
Что касается Ruby on Rails, то ситуация аналогичная. Использовать встроенный в фреймворк автокомплит в IDE(если ее рассматривать как надстройку над фреймворком) не должно составить труда
Для примера
Завтра-послезавтра, кто-нибудь сядет и напишет автокомплит для sublime text 2
Другой пример:
В руби все объект, у каждого объекта есть метод 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]
Супер! Это очень интересно, но почему же не рассказан хотя бы первый пункт? Жду продолжения с нетерпением!
Тут вроде пара перцев (Керниган и Пайк) что то подобное уже написали "UNIX — универсальная среда программирования".
Добавьте cmake в средства сборки и получите набор инструментов, способный удовлетворить потребности всех — и любителей различный IDE и тех, кто пишет в VIM + console.
Даешь «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. Они знают, что из себя представляет проект. Учитывают контексты, в которых написан код (классы, области видимости переменных, пэкеджи и пр.).
Позволяют быстро и эффективно собирать, рефакторить, редактировать, запускать проект без необходимости личного обращения к другим программам.
Я не отрицаю, что огромный набор юниксовых программ и утилит позволяет достаточно эффективно вести разработку простых и сложных проектов. И я поддерживаю автора оригинальной статьи и автора перевода в распространении знаний о возможностях 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. Они знают, что из себя представляет проект. Учитывают контексты, в которых написан код (классы, области видимости переменных, пэкеджи и пр.).
Позволяют быстро и эффективно собирать, рефакторить, редактировать, запускать проект без необходимости личного обращения к другим программам.
Если вы хоть когда-нибудь говорите фразу «да, это сарказм», то вы, извините, идиот)
По существу: если вы такой любитель придираться к словам, то IDE — это набор средств для разработки. Абсолютно неважно 1 это программа или 1000.
Ваша IDE тоже использует svn, с какого перепугу?
Лучшие программисты которых я видел, которые пишут самый адекватный код — из тех что я знаю, делают это в мощных текстовых редакторах. Будь-то jedit или vim или emacs или новомодный sublime. Я до глубины души считаю что IDE — это зло. Наша голова способна вмещать гигантское кол-во информации. И помнить классы/методы/параметры ко всему и вся — можно. Постепенно привыкаешь запоминать это с первого раза. Потом — привыкаешь писать ТАК, чтобы в следующий раз даже вспоминать НЕ НАДО было, так, что в следующий раз ты при использовании функции легко вписываешь те же параметры, как если бы писал функцию сейчас. Код становится куда проще для понимания при первом чтении. Рефакторинг становится проще и адекватнее. Даже баги становится проще чинить — потому что когда происходит хрень, ты уже *помнишь всё*. Не надо никуда лезть смотреть. Ты сразу предполагаешь что могло пойти не так. Для этого даже не нужно смотреть никуда — ты можешь такие проблемы решать *по телефону*. И вот это — дорогого стоит. А быть привязанным к IDE и даже никогда не набирать очень_вот_блин_длинную_функцию руками, и, как следствие, вообще со временем забыть какое окончание в названии у этой супердлинной функции — очень сочувствую я таким разработчикам.
С другой стороны, у меня есть знакомые разработчики которые работают в IDE. И они умудряются делать элементарные ошибки, потому что IDE им что-то там не подсветило. Систематически.
Если рассуждать так же как и я — то фраза «Unix как IDE» вполне адекватна. Я бы правда «как» заменил на «вместо».
Впрочем, когда то разработчики были двух каст — «натянутые» и те, кто настолько сильно любит это ремесло, что посветил ему такое коллосальное кол-во времени, что в моём опусе видит смысла больше, чем кажется. Первая каста — это как преподаватели информатики. Которые узнали что-то одно, а больше и не надо. Так вот сейчас спустя десяток лет эти две касты остались, но стали мизерными по сравнению с третьей, новой: программист-обычный. И «обычных» настолько много, что работа у разработчиков IDE будет всегда =).
Обидно только, разработчиков хороших теперь найти в 100500 раз сложнее стало =(
По существу: если вы такой любитель придираться к словам, то IDE — это набор средств для разработки. Абсолютно неважно 1 это программа или 1000.
Ваша IDE тоже использует svn, с какого перепугу?
Лучшие программисты которых я видел, которые пишут самый адекватный код — из тех что я знаю, делают это в мощных текстовых редакторах. Будь-то jedit или vim или emacs или новомодный sublime. Я до глубины души считаю что IDE — это зло. Наша голова способна вмещать гигантское кол-во информации. И помнить классы/методы/параметры ко всему и вся — можно. Постепенно привыкаешь запоминать это с первого раза. Потом — привыкаешь писать ТАК, чтобы в следующий раз даже вспоминать НЕ НАДО было, так, что в следующий раз ты при использовании функции легко вписываешь те же параметры, как если бы писал функцию сейчас. Код становится куда проще для понимания при первом чтении. Рефакторинг становится проще и адекватнее. Даже баги становится проще чинить — потому что когда происходит хрень, ты уже *помнишь всё*. Не надо никуда лезть смотреть. Ты сразу предполагаешь что могло пойти не так. Для этого даже не нужно смотреть никуда — ты можешь такие проблемы решать *по телефону*. И вот это — дорогого стоит. А быть привязанным к IDE и даже никогда не набирать очень_вот_блин_длинную_функцию руками, и, как следствие, вообще со временем забыть какое окончание в названии у этой супердлинной функции — очень сочувствую я таким разработчикам.
С другой стороны, у меня есть знакомые разработчики которые работают в IDE. И они умудряются делать элементарные ошибки, потому что IDE им что-то там не подсветило. Систематически.
Если рассуждать так же как и я — то фраза «Unix как IDE» вполне адекватна. Я бы правда «как» заменил на «вместо».
Впрочем, когда то разработчики были двух каст — «натянутые» и те, кто настолько сильно любит это ремесло, что посветил ему такое коллосальное кол-во времени, что в моём опусе видит смысла больше, чем кажется. Первая каста — это как преподаватели информатики. Которые узнали что-то одно, а больше и не надо. Так вот сейчас спустя десяток лет эти две касты остались, но стали мизерными по сравнению с третьей, новой: программист-обычный. И «обычных» настолько много, что работа у разработчиков IDE будет всегда =).
Обидно только, разработчиков хороших теперь найти в 100500 раз сложнее стало =(
Если честно, я тоже могу многое рассказать про людей, которые называют других идиотами.
Опять же, давайте не будем путать теплое с мягким.
Если человек не умеет толком писать код, то в этом вина не IDE, которая просто упрощает процесс разработки, а самого человека.
И с другой стороны, если человек профессионал, то он может хорошо писать и в блокноте и в IDE.
Если проводить простую аналогию, то дурак зарежет себя и собственным мечом, а мастер же может одолеть соперника простой палкой, но это не значит, что он обязан отказаться от меча.
Из личного опыта скажу: я писал программки на Java, пользуясь Vim'ом и вызывая компилятор из командной строки. Потом, по мере погружения в Vim и по мере надобности, он обрастал плагинами для автодополнений, разработки на Java, автоматизации тестов и пр.
Но когда я попал на свою первую работу и столкнулся с огромным code-base'ом, то программировать в Vim'е становилось все труднее и труднее.
В итоге я начал переходить на IntelliJ Idea и не пожалел, потому что это ускорило разработку в разы, т.к. теперь не надо было самому искать использования тех или иных методов, а также пытаться понять является ли класс Foo в коде из пакета foo.bar или foo.baz — IDE помогал сразу найти то, что нужно, отрефакторить что-либо, без необходимости тратить лишнее время на самостоятельные поиски юзов итд.
Ну и в конце, еще раз КРАТКО напишу основной посыл своего исходного комментария:
ДА, умение понимать и использовать оригинальные Unix'овые утилиты и программы для разработки — это хорошо, правильно и действительно работает.
НО НЕТ, это не то же самое, что полноценное IDE.
ТЕМ НЕ МЕНЕЕ, при должных навыках можно быть Гуру-программистом, даже просто используя hex-редактор, создавая сразу бинарный код.
Опять же, давайте не будем путать теплое с мягким.
Если человек не умеет толком писать код, то в этом вина не IDE, которая просто упрощает процесс разработки, а самого человека.
И с другой стороны, если человек профессионал, то он может хорошо писать и в блокноте и в IDE.
Если проводить простую аналогию, то дурак зарежет себя и собственным мечом, а мастер же может одолеть соперника простой палкой, но это не значит, что он обязан отказаться от меча.
Из личного опыта скажу: я писал программки на Java, пользуясь Vim'ом и вызывая компилятор из командной строки. Потом, по мере погружения в Vim и по мере надобности, он обрастал плагинами для автодополнений, разработки на Java, автоматизации тестов и пр.
Но когда я попал на свою первую работу и столкнулся с огромным code-base'ом, то программировать в Vim'е становилось все труднее и труднее.
В итоге я начал переходить на IntelliJ Idea и не пожалел, потому что это ускорило разработку в разы, т.к. теперь не надо было самому искать использования тех или иных методов, а также пытаться понять является ли класс Foo в коде из пакета foo.bar или foo.baz — IDE помогал сразу найти то, что нужно, отрефакторить что-либо, без необходимости тратить лишнее время на самостоятельные поиски юзов итд.
Ну и в конце, еще раз КРАТКО напишу основной посыл своего исходного комментария:
ДА, умение понимать и использовать оригинальные Unix'овые утилиты и программы для разработки — это хорошо, правильно и действительно работает.
НО НЕТ, это не то же самое, что полноценное IDE.
ТЕМ НЕ МЕНЕЕ, при должных навыках можно быть Гуру-программистом, даже просто используя hex-редактор, создавая сразу бинарный код.
Автор, у вас отличный слог, пишите дальше. Только жаль, что не включили хоть кусочек конкретики в первый пост. А тема интересная и, надеюсь, обойдётся без холиваров ;)
Sign up to leave a comment.
Unix как IDE: Введение