Приводит ли разработчик к более медленной машине разработки к более быстрому / более эффективному коду? [закрыто]

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

Этот вопрос состоит из двух частей ...

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

2) Что я могу сделать, чтобы дать своим разработчикам быстрый опыт IDE, в то же время предоставляя «типичный» опыт выполнения?

Обновить:

К сведению, я готовлю свой беспристрастный ответ руководству. Это не моя идея, и вы, ребята, помогаете мне исправить ошибочные запросы моего клиента. Спасибо, что дали мне больше боеприпасов, и указали, где и когда к этому подойти. У меня есть +1 допустимых вариантов использования, таких как:
- специальные оптимизации программирования на стороне сервера
- тестовые лаборатории
- возможно, покупка лучшего сервера вместо топовых линейных видеокарт

Абсолютно

Также верно, что менеджеры должны проводить все встречи на Pig-Latin. Это улучшает их навыки общения в целом, чтобы они были в невыгодном положении, когда произносили простые предложения. Им придется больше полагаться на выражения лица и язык тела, чтобы донести свою точку зрения, и мы все знаем, что в любом случае это по крайней мере 70% всего общения.

Финансовые директора должны использовать только счеты и мел. В противном случае они в конечном итоге слишком полагаются на «необработанные данные», а не на свои «интуитивные ощущения».

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

Ответ (я буду смелым и скажу) всегда

NO .

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

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

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

2) Дайте им каждый второй ПК, представляющий самые низкие характеристики, которые вы хотите, чтобы они фактически поддерживали, с переключателем KVM, чтобы переключаться между тем и их реальной рабочей станцией.

Мне нравится долгое время компиляции. Это дает мне больше времени для работы над моим резюме.

Это ужасная идея. Вы хотите, чтобы ваши разработчики были настолько продуктивными, насколько это возможно, а это значит, что они должны предоставлять им максимально быструю машину, чтобы они не сидели весь день в ожидании компиляции. (Немного ОТ, но это также помогает не блокировать их доступ к потенциально полезным сайтам с помощью WebSense и т. П.) Если вы ограничены наличием пользователей, которые все еще используют технологию Stone-Age, тогда вам понадобится тестовый компьютер с аналогичными характеристиками, и обязательно тестируйте рано и часто, чтобы убедиться, что вы не идете по неверному пути с точки зрения выбора технологии.

Разработка должна осуществляться в наилучшей возможной среде. Тестирование должно проводиться в худших условиях, которые возможны.

Если бы мне дали медленную машину, я бы потратил свой день на оптимизацию процесса разработки, а не на оптимизацию поставляемого кода. Итак: НЕТ!

Программисты встраиваемых систем сталкиваются с этим постоянно! И есть решение из двух частей:

1. Ваши требования должны указать производительность X на оборудовании Y.
2. Тестируйте на оборудовании Y, и когда вы не получаете производительность X, обнаружите ошибки в файлах.

Тогда не имеет значения, на каком оборудовании работают ваши разработчики.

Когда вы это сделаете, скажем, более быстрое оборудование может сэкономить вашим программистам полчаса в день или 125 часов в год. И скажем, они стоят 100 000 долларов в год с выгодами и накладными расходами (смехотворно низкими для Силиконовой долины), или 50 долларов в час. Эти 125 часов * 50 долларов в час - 6250 долларов. Так что, если вы тратите меньше чем $ 6250 в год на разработку аппаратного обеспечения для каждого программиста, вы экономите деньги.

Это то, что вы должны сказать своему руководству.

Тим Уиллискрофт в значительной степени сказал первую половину этого в комментарии, и в справедливом мире он получит половину баллов за этот ответ.

Добавлено 24 октября:

У моего бывшего работодателя была такая теория, и она помогла им разозлить около 100 миллионов долларов.

Это японский конгломерат, который использовался для найма программистов в Японии, Корее и Китае. Люди там классные с использованием дрянного оборудования для разработки, 13-часового рабочего дня, сна за партами и отсутствия жизни. Поэтому они решили, что когда они приобрели известную компанию в Силиконовой долине для разработки ОС для мобильных телефонов на базе Linux, те глупые калифорнийцы, которые хотели современное оборудование, были просто плаксивыми примадоннами и на самом деле не имели для этого веских причин (например, производительности).

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

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

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

В программировании существует старая поговорка о том, что « преждевременная оптимизация - корень всего зла ». Я думаю, вам удалось успешно создать еще один «корень» (или хотя бы первую ветвь) всего зла. Отныне мы можем сказать, что «преждевременная деоптимизация разработчика является корнем всего зла».

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

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

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

Что вам нужно сделать, это добавить этап в конце цикла разработки, где вы проводите приемочное тестирование в нижних границах. Конечно, часть кода будет слишком медленной из-за более быстрой машины разработчика, но вы можете изолировать эту часть и оптимизировать ее там. Остальная часть вашего кода остается чистой и поддерживаемой.

Я вижу, что ваш вопрос звучит так: «Могу ли я заставить своих разработчиков оптимизировать работу на ранней стадии, дав им плохие машины для разработчиков, но при этом получая хороший код?» И ответ нет.

Интересное чтение, все эти ответы.

Но я думаю, что большинство людей, отвечающих здесь, упускают суть. Вопрос, который я прочитал, заключается не в (по крайней мере) в том, чтобы действительно дать разработчикам P1 для более быстрого написания кода.

Дело в том, что сегодня многие программы работают так же медленно или даже медленнее, чем те программы, которые мы использовали в прошлом тысячелетии, несмотря на гораздо более мощные компьютеры. Судя по ответам, большинство разработчиков не понимают этого. Это очень очевидно в веб-приложениях. Этот сайт является очень хорошим исключением, но многие сайты имеют первую страницу размером в 1 Мб. Что я получу за ожидание загрузки? Я не знаю. Я думаю, что это похоже на невежество разработчика, не уважающего время, которое пользователь должен тратить на это, или даже хуже, если вы платите за мб. Дело в том, что все эти веб-страницы даже не содержат изображений с высоким разрешением. Часто это просто какой-то дерьмовый код, доставленный из какой-то среды разработки. Ну, конечно, это не дерьмовый код, я думаю, но он не дает никакой выгоды мне как пользователю.

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

Несколько недель назад я запустил ноутбук с 1995 года. Windows 3.x была запущена в кратчайшие сроки. База данных, из которой я должен получить некоторые данные, была запущена до того, как ключ ввода был полностью освобожден (по крайней мере).

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

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

Я предполагаю, что многие разработчики имеют нездоровый уровень адреналина. Да, я нашел способ вернуть некоторое разочарование всем ожидающим:
офисный сервер sql (запуск консоли управления) arcgis (запуск и использование) acrobat reader (запуск) agresso (используя, по крайней мере, в качестве веб-приложения) Windows (смотрит и использует, ну я еще не пробовал 7). NET веб-страниц (загрузка)

и так далее

Я чувствую себя хорошо :-)

Приветствия
Никлас

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

Мы создавали программное обеспечение в течение последних 6 десятилетий, и у нас до сих пор возникают такие вопросы? Похоже, еще одна попытка срезать углы. Без обид, но давай, ты думаешь, что вопрос даже логичен? Подумайте об этом в следующих терминах (если вы можете): вы хотите построить автомобиль 4x4, который может работать в суровых условиях, в дождь, в грязь и так далее. Собираетесь ли вы разместить своих инженеров и сборочную линию под элементами, чтобы убедиться, что полученное транспортное средство сможет на них работать?

Я имею в виду, Иисус Христос! Есть разработка и есть тестирование. Тестирование проводится в другой, более жесткой среде, или разработчик знает, как собрать испытательный стенд в своей собственной среде разработки способом, подходящим для стресс-тестирования. Если он не может, замените его на лучшего разработчика.

2) Что я могу сделать, чтобы дать своим разработчикам быстрый опыт IDE, в то же время предоставляя «типичный» опыт выполнения?

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

Но чтобы развлечь вопрос, дайте вашим разработчикам (при условии, что у вас есть хорошие разработчики), хорошие инструменты и хорошее оборудование, лучшее, что вы можете себе позволить. Затем установите самую низкую общую базовую среду, в которой должно работать ваше программное обеспечение. Вот где должно проводиться тестирование. Гораздо лучше в инженерной практике иметь среду тестирования , отличную от среды разработки (предпочтительно такую, которая позволяет проводить стресс-тестирование).

Если ваши разработчики хороши, они должны были сообщить вам об этом (при условии, что вы их спросили).

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

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

Я нарушу норму и скажу да, ЕСЛИ И ТОЛЬКО, если они пишут серверное программное обеспечение. Смейтесь сколько хотите, но самой эффективной командой, которую я когда-либо видел, была группа парней из Perl с терминалами Wyse. Это было в конце 1990-х, это был университетский магазин, и они писали программное обеспечение пространственной сетки (которое в основном просто вычисляет). Тем не менее, они разговаривали с некоторыми относительно мощными поздними моделями RS / 6000.

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

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

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

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

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

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

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

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

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

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

Во-вторых, если все работает медленнее, это означает, что вещи, которые вы, возможно, захотите делать на быстрой машине (занимает, скажем, 1 минуту), на медленной машине больше не осуществимы из-за лени и т. Д. Это вопрос стимула.

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

Точка 1, НЕТ! Студия предназначена для работы на приличных машинах, и это требование становится все более мощным с каждой версией. Вы можете заблокировать некоторые версии студии, если включите intellisense и используете одноядерный не HT-бокс.

К пункту № 2 в проектах тестирования есть некоторые функции, которые позволяют ограничить некоторые ресурсы. Они не идеальны, но они есть. VPC или образы виртуальных машин с низкой спецификацией - это довольно неплохая работа, если их ограничивать. У меня были пользователи, которые садились за плохие машины, чтобы время от времени проводить тестирование, чтобы они могли видеть последствия функций, которые они запрашивали.

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

Я думаю, что это интересный вопрос, и я бы не стал так быстро отвечать «нет». Мое мнение таково: это зависит от того, о какой развивающейся команде идет речь. Пример: если вы возглавляете группу, которая участвует в ежегодном конкурсе по программированию ICFP, возможно, хорошие результаты после небольшого времени разработки в кластере HPC не обязательно означают, что найденное вами решение является хорошим. То же самое можно сказать, если вы пишете какой-то научный или числовой алгоритм: на вашем старом AMD Duron 600 МГц с 64 МБ памяти вы вынуждены быть осторожными в том, как вы добиваетесь своей цели, и это может повлиять даже на некоторый дизайн выбор.

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

Одно можно сказать наверняка: быстрые машины и хорошие немедленные результаты приводят в замешательство (плохих) программистов и могут быть одной из причин того, что мы обнаруживаем на компьютерах все дерьмо.

Я работаю над пакетом, который занимает около часа, чтобы собрать мою 8-ядерную машину 8G (полная чистая сборка). У меня также есть относительно дешевый ноутбук, на котором я тестирую. Младший ноутбук не справляется с двумя полными сборками в течение одного рабочего дня.

Я более продуктивен на быстрой машине, когда на ноутбуке проводится целенаправленное тестирование, или я должен делать все свои сборки на ноутбуке?

Имейте в виду, что это не выдуманные цифры.

Это сфальсифицированная демонстрация, в которой мне обычно не нужно делать чистую сборку каждый день (я могу много тестировать на отдельных модулях), но даже частичные сборки показывают примерно на порядок разницу во времени компиляции / компоновки ,

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

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

Интересно, что я работал в стартапе, где мы закончили этим заниматься. Я думаю, что на самом деле это работало довольно хорошо, но только из-за конкретной ситуации, в которой мы оказались. Это был магазин mod_perl, где автоматическая перезагрузка классов работала правильно. Все разработчики использовали vim в качестве своей IDE (или использовали какое-либо программное обеспечение для удаленного редактирования). Конечным результатом было то, что очень мало (если вообще было) потеряно времени на ожидание компиляции / перезагрузки / и т.д. кода.

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

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

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

Я собираюсь остановить тенденцию и здесь.

Анекдот: Я работал в голландской фирме по разработке программного обеспечения, которая обновила 286 компьютеров до 486 (да, я такой старый). В течение нескольких недель производительность всех наших собственных библиотек упала на 50%, а количество ошибок возросло ... Небольшое исследование показало, что люди больше не продумали сам код во время процесса отладки, а обратились к «быстрому» последовательному коду -> compile -> test -> fix (code) и т. д. циклы.

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

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

Следовательно ... Я чувствую, что программисты должны быть вынуждены тестировать свои приложения на машинах, которые не превышают вычислительную мощность и аппаратные характеристики "Среднее число Джо".

Аппаратное обеспечение дешевле, чем время разработки.

Большинство узких мест находятся в базе данных, а не на клиентском ПК, но это не оправдывает тестирование на более медленных компьютерах, чем разработчик. Используйте инструменты тестирования для тестирования оптимизации.

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

Это интересная мысль (медленная работа разработчиков может привести их к дальнейшей оптимизации).

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

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

Другие ответили, что обычно вы хотите, чтобы у разработчиков были быстрые машины. Я согласен. Не пропускайте ОЗУ - вам нужно как можно больше памяти - некоторые процессы сборки очень сильно загружают диск.

То, от чего вы, возможно, захотите избавиться, это антивирус на сборочных дисках! Это только замедляет и может быть чрезвычайно сильным фактором замедления.

Вы можете позволить разработчикам разрабатывать на Linux, если это возможно. Инструменты там намного лучше для всех видов дополнительных задач (просто grep для чего-то в файле и т. Д.). Это также избавляет от антивируса.

Моему Macbook Pro на работе несколько лет. Между Linux и Windows (чтобы проверить причуды IE) vms, а также несколькими открытыми веб-браузерами и терминалами вращается колесо OSX. Угадай, что я делаю, когда он вращается, я сижу и жду. В этом случае медленная машина снижает производительность.

Для многих приложений проблема заключается в том, чтобы разработчики тестировали наборы данных реального мира до того, как они «закончили». Для интерактивных приложений потребуется базовый тестовый компьютер / ВМ.

Я работаю на медленной машине с Windows95, и это позволяет мне эффективно писать искусственный интеллект MindForth на Forth и на JavaScript.

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

При этом я, конечно, согласен с большинством: НЕТ .