Чи надає розробнику більш повільну машину розвитку, приводить до швидшого / більш ефективного коду? [зачинено]

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

Це питання має дві частини ...

1) Якщо я даю розробнику більш повільну машину, чи це означає, що отриманий код може бути швидшим чи ефективнішим?

2) Що я можу зробити, щоб дати розробникам швидкий досвід IDE, надаючи при цьому "типовий" досвід роботи?

Оновлення:

Для запису я готую свою рівномірну відповідь керівництву. Це не моя ідея, і ви допомагаєте мені виправити помилкові запити мого клієнта. Дякую за те, що ви подарували мені більше боєприпасів та вказували, де і коли слід до цього звернутися. У мене є +1 дійсні випадки використання, такі як:
- конкретні оптимізації програмування на стороні сервера
- тестові лабораторії
- можливо придбання кращого сервера замість верхньої лінії лінійних відеокарт

Абсолютно

Правда також, що керівники повинні проводити всі зустрічі на Свині-Латині. Це вдосконалює їхні комунікативні навички в цілому, щоб утилізувати їх, коли говорять прості пропозиції. Їм доведеться більше покладатися на міміку та мову тіла, щоб зрозуміти, і всі ми знаємо, що це як мінімум 70% усього спілкування.

Фінансові директори повинні використовувати лише абак і крейду. В іншому випадку вони надто покладаються на "необроблені дані", а недостатньо на "відчуття кишки".

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

Відповідь (я буду сміливою і скажу) завжди

НІ .

Розробіть найкраще, що ви можете отримати зі своїм бюджетом, і протестуйте на найменшій специфікації обладнання, яке ви будете розгортати.

Є емулятори, віртуальні машини, фактичні машини з тестерами, які можуть усі перевірити продуктивність, щоб побачити, чи є це фактором.

1) Дуже, дуже малоймовірно. Ні, і ваші розробники можуть поставити у вашу каву щось неприємне, щоб запропонувати це. Час, який розробники витрачають на очікування збору коду або для того, щоб IDE зробила все, що він робить, або будь-який час, який вони не витрачають на вдосконалення коду. Також порушує їх розумовий потік. Слідкуйте за проблемою, і вони будуть набагато ефективніше вирішувати цю проблему.

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

Мені подобаються довгі часи компіляції. Це дає мені більше часу на роботу над резюме.

Це жахлива ідея. Ви хочете, щоб ваші розробники були максимально продуктивними, це означає надати їм якомога швидшу машину, щоб вони не сиділи цілими днями і чекали, коли все складеться. (Трохи OT, але це також допомагає не блокувати їх доступ до потенційно корисних сайтів за допомогою WebSense тощо). Якщо ви обмежені тим, що користувачі, які все ще використовують технологію Stone-Age, вам знадобиться мати тестову машину з подібними характеристиками, і не забудьте тестувати рано і часто, щоб переконатися, що ви не йдете неправильним шляхом з точки зору вибору технології.

Розвиток повинен здійснюватися в найкращому середовищі, яке це можливо. Тестування слід проводити в найгірших умовах, що це можливо.

Якби мені дали повільну машину, я би провів свій день, оптимізуючи процес розробки і не оптимізувавши доставлений код. Отже: НІ!

Програмісти з вбудованими системами постійно стикаються з цим! І є рішення з двох частин:

1. Ваші вимоги повинні вказати продуктивність X на апаратному забезпеченні Y.
2. Перевірте апаратне забезпечення Y, і коли ви не отримаєте продуктивність X, подайте помилки.

Тоді не має значення, над яким обладнанням працюють ваші розробники.

Коли ви зробите це, скажімо, швидше обладнання може економити програмістів на півгодини на день або 125 годин на рік. Скажімо, вони коштують 100 000 доларів на рік із пільгами та накладними витратами (смішно низька для Силіконової долини), або 50 доларів на годину. Це 125 годин * 50 доларів на годину - 6250 доларів. Отже, якщо ви витрачаєте що-небудь менше 6250 доларів на рік на обладнання для розробки Rockin на одного програміста, ви економите гроші.

Ось що ви повинні сказати своєму керівництву.

Тім Вілліскрофт майже повністю сказав першу половину цього в коментарі, і в справедливому світі він отримає половину будь-яких балів, які отримає ця відповідь.

Додано 24 жовтня:

Мій колишній роботодавець мав цю теорію, і це допомогло їм зібрати близько 100 мільйонів доларів.

Це конгломерат із японського виробництва, який використовували для найму програмістів у Японії, Кореї та Китаї. Люди там приємно користуються лайливим обладнанням для розробки, 13-годинними робочими днями, сплять за столом і не мають життя. Тож вони подумали, коли придбали відому компанію Silicon Valley, щоб зробити ОС мобільного телефону на базі Linux, ті дурні каліфорнійці, які хотіли сучасного обладнання, були просто примхливими примадоннами і насправді не мали для цього вагомих причин (як продуктивність).

Через чотири роки ОС спрацювала як лайно, всі графіки були підірвані, а клієнти були розлючені і розірвали договори праворуч і ліворуч. Нарешті, проект ОС був скасований, і за останній рік було звільнено великий відсоток світової робочої сили конгломерата. І, чесно кажучи, я б не хотів, щоб я був одним із керівників, які мусили пояснити акціонерам, куди пішли всі ці гроші та зусилля.

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

І повільна передача, безумовно, була фактором. Зрештою, якщо ви знаходяться під пістолетом, щоб доставити вчасно, чи справді розумна штука навмисне уповільнити роботу?

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

Коротше кажучи, відповідь полягає в тому, що це лише сповільнить ваш час розвитку і ускладнить подальше обслуговування. Часи компіляції займуть більше часу, пошук коду на диску піде повільніше, пошук відповідей в Інтернеті займе більше часу, і НАЙБІЛЬШЕ головне, що розробники почнуть використовувати передчасову оптимізацію свого коду, щоб навіть можна було перевірити необхідну функціональність.

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

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

Що потрібно зробити, це додати фазу в кінці циклу розробки, де ви робите приймальні тести на нижню межу поля. Звичайно, якийсь код буде надто повільним через швидшу машину розробника, але ви можете ізолювати цю частину та оптимізувати її там. Решта вашого коду залишається чистою та ретельною.

Я бачу ваше запитання: "Чи можу я змусити моїх розробників до оптимізації на ранній стадії, надаючи їм бідні машини для розробників, але все ще отримують хороший код?" І відповідь - ні.

Цікаве читання, всі ці відповіді.

Але я думаю, що більшість людей, які відповідають тут, пропускають суть. Питання, як я читав, це не (лише принаймні) про те, як реально дати розробникам P1 зробити швидший код.

Справа в тому, що багато програмного забезпечення сьогодні так само повільно або навіть повільніше, ніж програмне забезпечення, яке ми використовували ще в минулому тисячолітті, незважаючи на набагато більш потужні комп'ютери. Судячи з відповідей, тут більшість розробників не натякають на це. Це дуже очевидно в веб-додатках. Цей сайт є дуже хорошим винятком, але багато сайтів мають головну сторінку в 1 mb. Що я можу чекати, щоб завантажити його? Не знаю. Я думаю, що, здається, йдеться про незнання з боку розробника, не дотримання часу, який користувачеві потрібно витратити на це, або ще гірше, якщо ви платите за mb. Вся справа в тому, що всі ці веб-сторінки навіть не містять зображень із високою роздільною здатністю. Часто це лише якийсь дерьмовий код, доставлений з якогось середовища розробки. Ну, звичайно, це не лайновий код, я думаю, але він не дає ніякої користі для мене як користувача.

Взагалі мова йде не лише про оптимізацію коду, а так само про вибір, щоб не включати речі, що сповільнюють більше, ніж це дає.

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

Я знаю, що ми сьогодні отримуємо набагато більше від свого програмного забезпечення, але у нас також є комп’ютери в багато разів швидше. Чому індустрія розвитку не вирішує зберегти швидкість програмного забезпечення з 1995 року і не змушує людей купувати нове обладнання, оскільки вони хочуть нової функціональності. Сьогодні це більше схоже на повсякденні програми та веб-сайти змушує людей купувати нове обладнання, щоб робити саме ті ж речі, що й раніше. Але, звичайно, у вигадливіший спосіб.

Треба сказати, я думаю, що розробка Linux, схоже, справляється з цим краще. Дистрибутиви Linux протягом багатьох років досить далеко випереджають вікна навіть у фантазії з багатьма очей цукерками, такими як анімовані вікна. Річ у тім, що вони, незважаючи на те, що працювали на комп’ютерах сьогодні і навіть вчора. Не тільки на найсучаснішому обладнанні.

На сьогодні я здогадуюсь, що багато розробників мають нездоровий рівень адреналіну. Так, я знайшов спосіб повернути розчарування від усіх, хто чекає перед:
сервер офісу sql (запуск консолі управління) arcgis (запуск та використання) зчитувача acrobat (запуск) agresso (використовуючи принаймні як веб-додаток) windows (дивлячись та користуюсь, ну я ще не пробував 7) .net веб-сторінок (завантаження)

і так далі

Я почуваюся добре :-)

Ура,
Ніклас

1) Якщо я даю розробнику більш повільну машину, чи це означає, що отриманий код може бути швидшим чи ефективнішим?

Ми розробляємо програмне забезпечення протягом останніх 6 десятиліть, і ми все ще отримуємо такі питання? Здається, це ще одна спроба вирізати кути. Без образи, але давай, ти вважаєш, питання навіть логічне? Подумайте про це в цих умовах (якщо можете): ви хочете побудувати транспортний засіб 4x4, який може працювати в суворих умовах, дощі, грязі та будь-якому іншому. Чи збираєтесь ви поставити своїх інженерів та конвеєр під елементи, щоб переконатися, що отриманий автомобіль може працювати на них?

Я маю на увазі, Ісусе Христе! Є розробка і є тестування. Тестування проводиться в іншому, суворішому середовищі, або розробник знає, як зібрати тестовий шар у власному середовищі розробників способом, придатним для тесту на стрес. Якщо він не може, замініть його на кращого розробника.

2) Що я можу зробити, щоб дати розробникам швидкий досвід IDE, надаючи при цьому "типовий" досвід роботи?

Ви повинні запитати це у своїх розробників. І якщо вони не можуть дати вам об'єктивну та достовірну відповідь, вам потрібно замінити їх фактичними розробниками.

Але щоб розважити питання, надайте своїм розробникам (припускаючи, що у вас хороші розробники), хороші інструменти та хороше обладнання, найкраще, що ви можете собі дозволити. Потім встановіть найменшу загальну базову середу, в якій повинно працювати ваше програмне забезпечення. Ось де має відбуватися тестування. Набагато кращою інженерною практикою є тестове середовище, яке відрізняється від середовища розробки (бажано такого, яке дозволяє робити стрес-тестування.)

Якщо ваші розробники будь-які хороші, вони повинні були повідомити про це вам (припускаючи, що ви їх запитали.)

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

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

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

Тільки щоб додати події до події, там був сліпий програміст. Я був ретельно вражений.

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

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

Деякі налаштування процесу складання VS можуть зробити розгортання до тестового поля нормою з віддаленою налагодженням.

Є й інші способи розглянути можливість змусити ваші кодери розробити більш ефективний код - ви можете включити цілі продуктивності та використання пам'яті у ваші тестові одиниці, наприклад. Визначення бюджетів для використання пам'яті також є видатною метою. Також встановлення бюджетів на вагу сторінки для html-коду.

Проблема не в тому, що розробник неефективний код на швидкій машині, проблема полягає в тому, що ви не визначили показники продуктивності, які потрібно вимірювати.

У рамках вимог до продукту слід визначити конкретну ціль, яку можна виміряти на всіх комп'ютерах, виходячи з необхідного досвіду клієнта. Існує багато веб-сайтів (Check SpecInt), які дозволяють зв’язати свій комп'ютер з іншими типами комп'ютерів.

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

Я переконаний, що повільніший комп'ютер для розвитку призводить до більш швидкого коду, але це ціна. Обґрунтуванням цього є те, що я пережив це з перших рук: маючи тривалий час на маршруті, я придбав нетбук для роботи в поїзді, нетбук якого повільніше, ніж будь-який комп’ютер, який я придбав за 5 останніх років. Оскільки все так повільно, я дуже швидко бачу, коли щось нестерпно повільно в цій нетбуці, і я знаю про повільні місця набагато швидше (не потрібно весь час орієнтуватися). Робота над нетбуком дуже змінила те, як я розвивався.

Попри це, я не виступаю за це, особливо в професійному середовищі. По-перше, це деморалізує. Сам факт, що майже всі говорили про цю ідею, навіть не мав сенсу, що програмісти погано реагують на цю ідею.

По-друге, все повільніше означає, що речі, які ви хочете робити на швидкій машині (займає, скажімо, 1 хвилину), насправді вже не виконуються на повільній машині через лінь тощо. Це питання заохочення.

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

Пункт 1, НІ! Студія покликана працювати на пристойних машинах, і ця вимога стає все більш потужною з кожною версією. Ви можете фактично заблокувати деякі версії студії, якщо увімкнути інтелігенцію та використати одноядерний ящик без HT.

До пункту №2 є деякі функції тестових проектів, які дозволяють зменшити деякі ресурси. Вони не досконалі, але вони є. VPC або низькоспеціальний VM-образи - це дуже хороша робота обмеження. У мене були користувачі сідати на погані машини, щоб періодично робити тестування, щоб вони могли бачити наслідки запитуваних ними функцій.

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

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

З іншого боку, розумний програміст / вчений / все, що завгодно повинно бути обережним. Але я виявив, що я записував деякі з моїх найкращих кодів, коли в мене НЕ ВІДОМУВАТИ комп’ютер і треба було робити нотатки на папері. Це може не стосуватися великих проектів, що передбачають величезні рамки, коли IDE вкрай необхідний.

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

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

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

Майте на увазі, це не складені номери.

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

Тож справжнє питання полягає в тому, що на моїй повільній машині типова конструкція досить довга, щоб я міг випити чашку кави, тоді як на моїй швидшій машині я можу випити трохи кави.

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

Цікаво, що я працював у стартапі, де ми закінчилися цим займатися. Я думаю, що насправді це спрацювало досить добре, але тільки через специфічну ситуацію, в якій ми опинилися. Це був магазин mod_perl, де автоматичне завантаження класів насправді працювало коректно. Усі розробники використовували vim як свій IDE за вибором (або використовували деяке програмне забезпечення для віддаленого редагування). Кінцевим результатом було те, що дуже мало (якщо є) часу було втрачено в очікуванні збору / перезавантаження / тощо.

В основному, мені подобається ця ідея IFF, це незначно впливає на цикл розробки для всіх розробників, і це лише впливає на час роботи вашого коду. Якщо ваш код все-таки компілюється, попередньо обробляється тощо, тоді ви додаєте час для циклу "виправити помилку; тест; наступний", над яким розробники працюють.

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

Після перечитування вашого оригінального запитання мені здається, що одне, що мене постійно страшно, - це середовище розробки, яке відрізняється від виробничого середовища. Чому б не використовувати VM для виконання коду, який можна покалічити під час виконання, не впливаючи на робочу станцію розробника? Останнім часом я використовую / люблю VirtualBox.

Я також збираюся підірвати тенденцію і тут.

Анекдот: Я працював у голландській фірмі з розробки програмного забезпечення, яка модернізувала 286 комп’ютерів до 486-х (так, я така стара). Протягом тижнів продуктивність усіх наших власних бібліотек знизилася на 50%, а помилки збільшились ... Невелике дослідження показало, що люди вже не замислювалися над самим кодом під час налагодження, але вдалися до «швидкого» послідовного коду -> цикли компілювати -> тест -> виправити (код) тощо.

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

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

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

Обладнання коштує менш затратно, ніж час розробки.

Більшість вузьких місць знаходяться в базі даних не на клієнтському ПК, але це не виправдає тестування на повільних машинах, ніж розробник. Використовуйте інструменти тестування для тестування оптимізації.

Абсолютно ні. Дайте програмістам найкращі гроші на ноутбук, які вони можуть обрати, клавіатуру на свій вибір, кілька великих великих екранів, приватний офіс, без телефону, безкоштовні безалкогольні напої, всі книги, які вони хочуть (які є необхідними), щорічні поїздки на ключові технічні конференції та ви отримаєте чудові результати. Потім перевіряйте комбінації верхнього та нижнього кордону обладнання / програмне забезпечення / браузер / пропускна здатність.

Це цікава думка (подання розробникам повільної машини може привести їх до оптимізації більше).

Однак рішення створено кращим способом - покладіть час відгуку на вимоги до програм та майте низькопробну машину для тестування.

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

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

Можливо, ви хочете розглянути можливість позбутися - це антивірус на накопичувачах збірки! Це лише уповільнює і може бути надзвичайно сильним фактором уповільнення.

Ви можете дозволити розробникам розвиватися в Linux, якщо це можливо. Інструменти там набагато кращі для будь-яких додаткових завдань (просто натисніть на щось у файлі тощо). Це також позбавляється від антивірусу.

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

Для багатьох застосунків проблема полягає в тому, щоб розробники протестували набори даних у реальному світі, перш ніж вони будуть "готові". Для інтерактивних застосувань потрібна буде випробувальна машина / VM.

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

Запитувати програмістів, чи повинні програмісти отримати гарне обладнання - це як запитати товстуна, чи любить він їжу. Я знаю, що це суб'єктивний обмін, але все-таки ... чи варто нам ставити це питання? : P

Це сказало, я, звичайно, згоден з більшістю: НІ .