TECH · 19 ноября 2013, 08:57 · Adrelian
Культура IDE против философии Unix

Автор сегодняшней нашей статьи Майкл О'Чёрч хоть и утверждает, что исповедует либертарианский подход к разработке, тем не менее достаточно горячо выступил против использования IDE в работе, поскольку, с его точки зрения, они противоречат «философии Unix». А также он попытался проанализировать, почему же эти инструменты настолько распространены в корпоративной среде.

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

Подробнее об IDE-зависимости у посредственных программистов, почему IDE так популярны среди менеджеров и в крупных корпорациях и в чем собственно использование IDE противоречит "философии Unix".

  • проблема «полноприводного двигателя». Это явление связано с тем, что если неопытный водитель попытается проехать по бездорожью на полноприводном автомобиле, то рано или поздно застрянет. Сев за руль такого автомобиля, новичок просто успеет подальше забраться в глушь, прежде чем машина откажет. IDE оправдывают себя, когда с их помощью вам удается поддерживать чей-то страшно некачественный код, который без IDE был бы совершенно неуправляемым комом противоречий. Благодаря IDE даже самый отвратительный код может показаться сносным. Думаю, с этим согласятся все. Проблема в другом: наделяя вас такими возможностями, IDE подталкивают к довольно сомнительной практике. Мы начинаем постоянно гнать разработку вперед, мирясь даже с вопиюще некачественным кодом, когда необходимость исправить или полностью переписать плохой код становится очевидна всем. IDE позволяют отсрочить возникновение проблем с качеством кода и оттянуть масштабные бизнес-последствия. И это устраивает менеджезавров, обожающих жесткие дедлайны, но только усугубляет проблему в итоге.
  • IDE-зависимость.  Практики программирования, развивающие у разработчика зависимость от конкретной рабочей среды, просто непростительны. Причем неважно, о какой именно среде идет речь — Emacs, vi или Eclipse. Серьезная проблема IDE заключается в том, что они развивают у вас привычку работать таким образом, что переход в новую среду разработки крайне осложняется. Один из наиболее одиозных примеров такого рода находим в культуре Java: извращение принципа работы в командной строке, заключающееся в применении каталогов-синглтонов «src» и «com», но многие проблемы лежат гораздо глубже. Хуже того, из-за распространения IDE работу могут получить и такие «программисты», которые не знают, что такое система сборки и даже контроль версий. Им кажется, что о таких вещах уже позаботились «какие-то умники», а ширпотребному программисту достаточно уметь штамповать классы по требованию начальника.
  • Спагеттификация. Я убежден, что хорошая IDE должна быть доступна только для чтения. Желательно, чтобы она могла обслуживаться через Веб. Считаю, что навигация по коду помогает любому, кому приходится читать код, независимо от его качества. Когда вы видите имя, у вас должна быть возможность щелкнуть по нему и посмотреть, где это имя определено. С другой стороны, для меня не менее очевидно, что автоматический рефакторинг — порочная вещь. IDE позволяет с легкостью «внедрять» в программу любые абстракции, из-за чего со временем она превращается в спагетти-код, где все делается повсюду. Без IDE есть только один способ выполнить подобную работу — написать скрипт. Это оказывает на процесс разработки два эффекта. Во-первых, на внесение любых изменений требуется время, может быть, полчаса. И это хорошо: ведь если скрипт приведет к изменениям, которые отразятся на работе каждого, об этих изменениях придется поговорить, и такая беседа продлится явно дольше, чем полчаса. Во-вторых, такую работу смогут выполнить только настоящие программисты — по крайней мере, понимающие, что такое «скрипт» и «командная строка».
  • Время, затрачиваемое на поддержку среды разработки. Как только компания решает использовать для работы «вот эту среду» — обычно речь идет об IDE с различными корпоративными надстройками — IDE начинает обрастать разнообразными плагинами, порой довольно некачественными. Ее приходится поддерживать, появляется масса постылой работы, которой никто не хочет заниматься.

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

По моему опыту, именно в таких средах разработки, которые значительно зависят от IDE, получается наиболее дремучий спагетти-код, объектно-ориентированная сумятица и прочие монструозности, которые просто не мог написать полный идиот. Ему помогли. Автоматический рефакторинг, из-за которого код переполнился бессмысленными абстракциями? Зависимость от инъекций? Корявые паттерны? Да, в них все дело.

Кстати, в последнее время я стал глубже изучать язык C, так как все плотнее занимаюсь машинным обучением и понимаю, насколько важно уметь судить о производительности и какие исчерпывающие знания вычислений для этого требуются. Как минимум необходимо свободно изъясняться на языке C. Я прорабатываю книгу Зеда Шоу «Learn C the Hard Way», где автор высказывает ряд блестящих мыслей о программировании как таковом. Во вступительной главе он предупреждает, что при обучении не следует пользоваться IDE, а также поясняет свою точку зрения:

IDE или “интегрированная среда разработки” просто отупляет вас. Если вы хотите стать хорошим программистом, такие инструменты вам противопоказаны, так как они скрывают от вас суть процесса, а вы должны совершенно четко представлять, что делаете. Они полезны, если нужно срочно решить какую-то задачу, а платформа построена на базе определенной IDE. Но если вы учитесь писать код на C (а также на многих других языках), IDE просто бессмысленны. [...]

Да, вы пишете код довольно быстро, но можете программировать только на этом языке и только на этой платформе. Неудивительно, что некоторые компании столь охотно продают вам эти IDE. Они знают, что вы ленивы. Обзаведясь IDE, вы оказываетесь заключены на ее платформе — только потому, что вы ленивы. Чтобы разорвать этот порочный круг, нужно сжать зубы и наконец-то научиться программировать без IDE. Вы по-настоящему освоите работу с кодом в простейшем текстовом редакторе или в программерском редакторе — например Vim или Emacs. Да, поначалу это не так просто, но в итоге вы научитесь работать с любым кодом, на любом компьютере, на любом языке, так как будете понимать, что делаете (выделено мною — авт.)».

Не могу согласиться с пассажем «IDE отупляет вас». Опираясь на нее, кодер в принципе не умнеет, но я не думаю, что такой инструмент действительно вызывает деградацию способностей программиста. Программирование в больших корпорациях (масса работы по техподдержке, низкая продуктивность, полдня теряется на митинги, сложности с выбиванием разрешения на занятия интересными задачами, плохие исходники) действительно со временем разрушает личностные навыки, но дело здесь не только в IDE. Тем не менее, в целом я с ним согласен. Большинство ярых сторонников IDE — это посредственные программисты, знающие всего один язык и одну среду. К тому же такие люди не развиваются, так как не понимают, что именно происходит в коде. Подобные кадры губительны для софтверной индустрии. Программист обязан развиваться, если он этого не делает — его следует уволить.

Проблема с IDE заключается в том, что каждая корпоративная культура разработки подстраивает IDE под себя. При этом среда программирования становится настолько необременительной и простенькой, что дома, без любимой IDE, вы фактически ничего не можете написать. Для людей вроде меня, которые в принципе не любят такую среду, это не представляет проблемы, так как я вполне сносно программирую и без этих прибамбасов. Но если кто-то скатился в ритуальное программирование, так как сразу начал работать неправильно и уверен, что любая разработка должна протекать только в IDE (а больше-то он ничего и не видел), то он перестает быть программистом в 18:01 каждый будний день. У новичков зачастую даже не хватает навыков, чтобы самостоятельно настроить знакомую им среду разработки. Базовые навыки нужно приобретать там же, где ими овладели все великие программисты — в командной строке. И человек останавливается в развитии не потому, что хочет этого, а из-за простого непонимания, что же такое «программирование» на самом деле.

Самое большое бедствие, свойственное этим на первый взгляд насыщенным корпоративным средам, — это отсутствие документации. При работе с Unix и инструментами командной строки вы всегда найдете в Интернете man-справку и практические руководства. Такие ресурсы стимулируют иную культуру, где каждый умеет решать стоящие перед ним проблемы. Имея достаточно времени, вы сможете найти ответы на любые ваши вопросы. Именно на таком материале вы и растете: не знаете, как что-либо работает, гуглите полученное сообщение об ошибке, получаете результат. Подобные знания приобретаются не за один день, зато они получаются глубокими. Этот процесс не работает в чрезмерно усложненной корпоративной среде. Чтобы немного продвинуться в решении проблемы, приходится отвлекать от работы знающего человека. А трата рабочего времени на реальное самообразование кажется многим менеджерам неприемлемой.

Здесь я снова хотел бы процитировать Зеда Шоу («Learn C the Hard Way», глава 3):

В разделе "Дополнительное задание" к каждому упражнению я иногда ставлю перед вами задачу самостоятельно найти информацию и разобраться в проблеме. Это важное умение самодостаточного программиста. Если вы постоянно обращаетесь к кому-то с вопросами, а не пытаетесь разрешить их своими силами, то никогда не научитесь решать проблемы независимо. Следовательно, вы никогда не будете уверены в собственных навыках и всегда будете нуждаться в ком-то, кто возьмет на себя часть вашей работы. Чтобы избавиться от такой вредной привычки, первым делом постарайтесь самостоятельно ответить на вопрос, а также проверить, правилен ли ваш ответ. Для этого придется докапываться до сути, экспериментировать с возможными вариантами ответа и проводить собственные исследования (выделено мною — авт.)».

Читатель уже понимает, что я выступаю против феномена «посредственного разработчика». В апреле прошлого года я писал статью «Java Shop Politics», касающуюся той же темы. Теперь я считаю, что зря выделил только язык Java, противопоставляя его C#, VB или даже С++. Я считаю, что любая компания, подчеркивающая свою приверженность любому языку X, работает неправильно. Корень зла не в самом языке Java, каким бы ограниченным он ни казался, а в культуре Большой Софтверной Компании. Именно в таких условиях множатся посредственные разработчики и вырождается сама идея объектно-ориентированного программирования, которое в настоящее время ушло уже достаточно далеко от идей Алана Кея.

В хорошо управляемых софтверных компаниях программы пишутся для решения проблем. Если проблема решена, это означает, что программа ГОТОВА. В будущем эта программа может потребовать адаптации или технической поддержки, но изначально это не предполагается. Не ведется разговоров о том, сколько штатных работников потребуется задействовать на текущую поддержку программы после завершения ее разработки. Если когда-нибудь потребуется изменить программу, это будет сделано. Программа решает четко поставленную проблему, после чего ее авторы переходят к решению новых задач. Боже упаси от программ, постоянно обрастающих требованиями. Отношение «программист-программа» должно строиться по принципу «один ко многим». Именно в такой ситуации начинается написание программ «по мере необходимости». Единственная проблема такого подхода в том, что он требует микроуправления небольшими программами, которые могут быть достаточно важными. Это и не устраивает «менеджезавров», привыкшим отслеживать выработку. Не нравится это и нерадивым сотрудникам, которым сложнее понять, к кому обратиться за помощью и когда именно дела пойдут плохо. Такая ситуация не возникает лишь в случае, когда работа каждого отдельного программиста отслеживается лишь его непосредственным клиентом, и человек может тихо делать очень важную работу (например, понемногу оптимизировать алгоритмы ядра, снижающие нагрузку на сервер). Но ведь можно выстроить и противоположную систему: множество разработчиков трудится над огромной программой, Которая Делает Сразу Все. Это порочный путь программирования, но именно к нему нас подталкивает активное использование IDE. Дело в том, что для настройки огромной общекорпоративной IDE требуется проделать немалый объем работы, поэтому такая настройка выполняется всерьез и надолго. Это и привлекает менеджеров, желающих руководить Огромными Проектами, на которых легко поддерживать однородность кадрового состава. В этом коренится политика использования одного языка. Хотя менеджеры ее и обожают, она зачастую оказывается бессмысленной.

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

Существуют ли успешные исключения из философии Unix? Да, но они встречаются редко. Классический пример работоспособной большой программы — это база данных, к подсистемам которой зачастую предъявляются очень жесткие требования (транзакции, производительность, параллелизм, выносливость, отказоустойчивость). Базу данных просто невозможно собрать из небольших программ, так сказать, органически вырастить. Чтобы создать работоспособную базу данных, требуется определенная высокоуровневая координация. Ведь в случае с базой данных бизнес-требованиями нельзя пренебрегать, они критически важны. Postgres — на мой взгляд, наилучшая из существующих SQL-баз, совсем не проста. Кстати, в базах данных нарушается один из основных принципов философии Unix — хранение данных в виде обычного текста. На то есть веские причины (рациональное использование носителей информации).

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

Я считаю, что очень многие айтишные менеджеры ошибаются, думая, что руководят разработкой какого-то исключительного продукта. Вот-вот их Большая Система (подобная Postgres) вырастет и станет настолько важной, что люди смирятся с ее сложностью и начнут ею пользоваться, так как эта Система станет чем-то более масштабным, чем Postgres или ядро Linux. Практически всегда они ошибаются. История корпоративной разработки напоминает слоновье кладбище, усеянное останками таких огромных систем. Исключения из философии Unix встречаются крайне редко. Можете быть уверены, что ваш корпоративный суперпродукт таким исключением не является. Если вдобавок большинство ваших посредственных разработчиков не могут писать код вне вашей IDE, то вам не позавидуешь.

Майкл О’Чёрч

Источник

Новые комментарии

Обсуждение

Missing-male
+7

Бла, бла, бла. Сильное подозрение, что он никогда бизнес приложения и не писал.

Missing
+4

поклоняющиеся командной строке такой ерундой не занимаются

4e0b0e17a2fe69fb41c683e00a19e4e6?1499980864
+3

Системы, написаные на ЯП с динамической типизацией (аля Python, где значительная часть разработчиков используют текстовые редакторы), Вы не относите к "бизнес приложениям"?

Пожалуста, дайте комментарий на то, что Вы считаете "бизнес приложениями"? Чем определяется сложность "бизнесс приложения" (я так понимаю это причина использования IDE)?

Missing
+8

"Полагаю, что правильная организация труда такова: инженер должен заниматься разработкой нескольких небольших самодостаточных программ. В этом и есть суть так называемой «философии Unix»." - вот видимо там, где для решения проблемы недостаточно нескольких небольших программ, начинаются "бизнес приложения". Они же приложения для конечного пользователя. А «философии Unix» это когда программисты пишут для программистов десять маленьких тулзеней. Те потом выход одной скармливают на вход другой в консоли, чем невьебенно повыщают ЧСВ. И это скорее субкультурное явление, чем профессиональное. Знаю весьма пожилого препода в универе, который просто ненавидит линуксоидов с их консолями: "я сорок лет трахался с этими командными строками еще со времен бэсма. И тут ко мне приходит молодняк и заявлет, что это классно." У него реально челюсть отвисает от такого говноедства.

"Системы, написаные на ЯП с динамической типизацией (аля Python, где значительная часть разработчиков используют текстовые редакторы)" - это классно, но речь скорее про:

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

и это:

"И человек останавливается в развитии не потому, что хочет этого, а из-за простого непонимания, что же такое «программирование» на самом деле." - ога, а вот автор знает. Но не рассказывает нам=))

"Не могу согласиться с пассажем «IDE отупляет вас». Опираясь на нее, кодер в принципе не умнеет, но я не думаю, что такой инструмент действительно вызывает деградацию способностей программиста." - в сотый раз читая такие пассажи от фанатиков консоли понимаешь, кто консоль отупляет не меньше.

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

в общем, КГ/АМ

Missing-male
Алексей Данченко
– Инженер-программист в ЛюксСофт

+4

В очередной раз не понимаю, зачем переводить статью из чьего-то бложика, не несущую в себе ни одной интересной мысли. Частное мнение, довольно радикальное, высказанное уже до этого товарища в тысячах статей и обсуждений. Зачем это на dev.by? Вызвать какие-то споры в комментариях среди тех, кто не спорил об этом 5-10-15 лет назад?

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

Ee0de4fca84c8c3e0d8dbe3424baf643?1401052271
+2

Статья оригинала в блоге на жирном вордпрессе и хранится в толстой БД, так что автор сам обладает здравым смыслом и понимает разницу между теоретическим идеализмом и практической действительностью.

Вот высказывания про IDE сомнительные. Современные IDE строятся как раз по принципам *nix и складываются из ядра и небольших плагинов, это позволяет гибко поддерживать разные ЯП, фреймворки, системы контроля версий и т.д.

238bc0582f41f2703b987bd6f9aef375?1401052542
+1

А я отчасти согласен с автором.

В том плане, что терпеть не могу когда IDE пладит свою структуру проектов с кучей дополнительных конфигов, артефактов и прочее. И получается что кроме того, что мне нужно разбираться в опциях компилятора, макроязыках для компиляции сорскников (make, nmake), мне нужно еще и прочитать книжку в 1000 страниц как сделать все просто с такой то IDE. И все это нужно уметь собирать из консоли когда прикручиваешь Continous Integration если не поддерживается IDE в Continous Integration сервере, а это 100500 человеко часов на изучение всяких тонкостей настройки.

Сейчас использую для C++ IDE Qt Creator - он поддерживает qmake и cmake (в том числе и без Qt) проекты и генерит только один (!) дополнительный файл - файл текущей настроики IDE.

Для скриптовых языков - Vim, Emacs, еще redcar иногда.

Для perl еще бывает юзаю Padre, когда нужно рефакторить код сильно.

До этого юзал MSVS, NetBeans.

MSVS подходит только для WIndows и работающая только с решениями от Microsoft. Если где то надо заюзать что либо отличное от Microsoft, то разобраться во всей этой свалке файлов становится тяжело.

У NetBeans есть одна killer фича - удаленная компиляция, но если она не нужна, опять гора своих файлов.

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

Слышал JetBrains готовит С++ IDE на основе cmake. Вот это будет интересно посмотреть.

Missing-male
+6

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

F2b89625907ec99f6cba80b077cfac09?1499980816
+10

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

- Зависимость от личного транспорта, а зачастую и привыкание к конкретной марке. Вы уже на крючке, и на вас делает деньги не только автопром, но и заправки, СТО, шиномонтаж и т.д.

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

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

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

Missing-male
+2

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

Почему бы "философии UNIX" не существовать в своих пещерах, где её лелеют трудолюбивые гномы, высекающие искры гениального кода из консолей. Да не зайдут туда комбайны IDE, RAD и CAD. Когда-нибудь туда спустятся археологи и найдут прекрасно написанные никому не нужные и никому не понятные произведения искусства.

Чего ополчились на автора? Бизнес-приложения какие-то, продуктивность-производительность... Кому, зачем? В Красную Книгу таких заносить и бесплатный хостинг за вредность выдавать.

7df30b74d305843fa914ee4b84813649?1500406519
+8

- Слушай, а какая система контроля версий у вас на проекте?

- А я не знаю, я просто кнопку каждый раз жму и оно само обновляет

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

Bb82f9c0ad8ad14b01621609b5cd3f79?1501076382
krasoffski
– Синьор-Помидор в EPAM

+3

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

Ответ прост: «Нет». Графические интерфейсы сами по себе прекрасны, и с их помощью многие простые операции выполняются быстрее и с большим удобством. Перемещение файлов, чтение сообщений электронной почты с кодировкой MIME и набор текстов писем – это все то, что вы хотели бы осуществлять в графической среде. Но если выделаете всю работу, используя графический интерфейс, то используете далеко не все возможности, предоставляемые операционной системой. И вам не удастся автоматизировать обычные задачи или использовать доступные инструментальные средства в полную силу. И вы не сможете комбинировать свои средства для создания специализированных макроинструментов. Преимуществом графического интерфейса пользователя является принцип WYSIWYG – что видишь, то и получаешь. Недостатком графического интерфейса можно назвать принцип WYSIAYG – получаешь только то, что видишь.

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

(c) Эндрю Хант, Дэвид Томас Программист-прагматик Путь от подмастерья к мастеру

Missing-male

Это ГБЦ для 4-к на фото?

Picture_3860?1356409918
+1

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

Пфф. IDE. Придумали невесть что. Блокнот наше все. И не дай бог взять что то получше - сразу клеймят еретиком. Ведь становишься на неправедный путь к IDE!


Авторизуйтесь, чтобы оставлять комментарии

© 2008-2017 Частное предприятие "Дев Бай"
Использование материалов, размещенных на сайте, разрешается при условии прямой гиперссылки на dev.by. Ссылка должна быть размещена в подзаголовке или в первом абзаце публикации.
datahata — хостинг в Беларуси