Чи мертва наука обчислювальної техніки? [зачинено]

Питання: Чи мертва наука та мистецтво КС? Я маю на увазі, що реальні вимоги до мислення, планування та ефективного вирішення проблем, здається, відпадають сьогодні від CS. Здається, поле знижує бар'єр для входу, тому більше людей можуть «програмувати», не навчившись справді програмувати.

Передумови: Я недавній випускник, який отримав ступінь бакалавра комп'ютерних наук. Я працюю на вихідній посаді в пристойній компанії в ІТ-відділі. Я здебільшого займаюся .NET та іншими технологіями Microsoft на своїй роботі, але до цього я робив речі Java через стажування тощо. Я особисто є програмістом на C ++ для власних розважальних проектів.

У глибині: Завдяки роботі, яку я виконував, мені здається, що напружені дисципліни реальної науки вже не існують у КС. Раніше програмістам довелося ефективно вирішувати проблеми, щоб системи були надійними та швидкими. Але зараз, завдяки переважаючим технологіям, таким як .NET, Java та мови сценаріїв, здається, що ефективність та надійність торгуються для зручності розвитку.

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

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

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

Це те, на що я буду з нетерпінням чекати все життя? Чи є ще позиції для людей, які люблять науку та мистецтво CS, а не просто зарплату?

І на ту саму ноту, ось добре прочитайте, якщо ви ще не бачили її перед школами Perils Of Java

Так і ні

Хороше запитання, але погане припущення.

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

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

На жаль, ця частина деяких "CS" навчальних програм (навчальних програм?), Здається, повністю опущена, замінена проблемами з іграшками тривіальними чи відомими рішеннями і покликана лише навчити знайомство з інструментами

Розчарування; багато випускників шкіл Java були недоопрацьовані, ніколи не навчали розв'язувати проблему, розробляти алгоритм, задавати тест або навіть ефективно налагоджувати.

Чи померла наука з комп’ютерних наук? "..." Я недавній випускник бакалавра з комп'ютерних наук. Я працюю на вихідній посаді в пристойній компанії в ІТ-відділі .

Чесно кажучи, два мої центи: "Науку" інформатики ви не знайдете, працюючи в ІТ-відділі в компанії пристойного розміру, адже це ІТ-відділ, а не відділ CS. Спробуйте повернутися в школу до доктора наук або працювати в інженерних відділах компанії, в центрі уваги якої - інформатика (наприклад, обробка зображень, високопродуктивні мережі, системи комп’ютерної алгебри, аерокосмічний тощо). Тут ви знайдете важкі цікаві проблеми, коли неохайний дизайн [як правило] не буде терпимим.

"Чи є ще позиції для людей, які люблять науку та мистецтво CS, а не просто зарплату?"

Так, абсолютно, але, мабуть, не в ІТ-відділах середніх компаній.

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

Це ІМО, де бізнес відповідає теорії. У таких типах випадків стара приказка «ворог кращого є достатньо доброю» може бути легко перевернута, щоб прочитати «ворог достатнього добра є кращим». Вважаючи себе "інженером" замість "вченого", а те, що ви робите паралельно з іншими інженерними дисциплінами, кидає відмінності на полегшення.

Скажімо, до вас приходить клієнт, інженер з будівництва / будівництва, і просить побудувати міст. Міст повинен бути простягнутий 20 футів, підтримувати себе і одна тонна переносити навантаження, він повинен тривати 10 років при регулярному обслуговуванні, і вони хочуть його через місяць за 20 000 доларів. Це ваші обмеження; відповідати мінімумам, не перевищуючи максимумів. Робити це "досить добре", і ви отримуєте зарплату. Для вас було б поганою інженерією побудувати міст Голден-Гейт, що значно перевищує як проектні характеристики, так і бюджет на кілька порядків. Зазвичай ви їсте перевищення витрат і сплачуєте штрафні санкції за перевитрати за час. Було б також поганою технікою для вас побудувати мотузковий мост з вагою 5 дорослих чоловіків, хоча це коштувало лише 1000 доларів у часі та матеріалів; ви не отримуєте хороших відгуків і відгуків клієнтів,

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

Якщо ви думаєте, що це випадкові випадки, ви помиляєтесь; це щоденне середовище більшості власників. Причина - ROI; ця початкова програма не коштує багато коштів і, таким чином, окупить себе дуже швидко. КОЛИ кінцеві користувачі потребують цього, щоб зробити більше або піти швидше, код можна змінити наново та змінити.

Це головна причина поточного стану програмування; припущення, що підтверджується всією історією обчислень, полягає в тому, що програма НІКОЛИ не статична. Його завжди потрібно буде модернізувати, і з часом він буде замінений. Паралельно постійне вдосконалення комп'ютерів, на яких запущені програми, дозволяє зменшити увагу до теоретичної ефективності, а також підвищити увагу до масштабованості та паралелізації (алгоритм, який працює в N-квадратний час, але який може бути паралельний для роботи на N ядрах) здаються лінійними, і часто вартість більшої кількості апаратних засобів дешевша, ніж розробники для розробки більш ефективного рішення).

Крім того, існує дуже простий принцип, що кожен рядок коду розробника - це щось інше, що може піти не так. Чим менше розробник пише, тим менше ймовірність того, що те, що він пише, має проблеми. Це не критика чиєїсь "помилки"; це просте твердження факту. Ви можете знати, як записати MergeSort назад і вперед на 5 мовах, але якщо у вас просто-на-пальчику лише один ідентифікатор в одному рядку коду, весь сортування не працює, і якщо компілятор не впіймав його, це може зайняти вас годин для його налагодження. Контрастуйте це з List.Sort (); це там, це ефективно в загальному випадку, і ось найкраще, воно вже працює.

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

• OOP - вбудовуйте пов'язані дані та логіку в об'єкт, і де б поняття цього об'єкта не було чинним, тому це об'єкт, або більш спеціалізоване виведення.
• Попередньо вбудовані шаблони - хороші 60% або більше коду - це синтаксична суть і основи отримання програми показати щось на екрані. Стандартизувавши та автоматично генерувавши цей код, ви зменшите навантаження розробника вдвічі, що дозволяє підвищити продуктивність.
• Бібліотеки алгоритмів та структур даних - Як і у вищесказаному, ви можете знати, як писати стек, чергу, QuickSort тощо, але навіщо це робити, коли є бібліотека коду, у яку все це вбудовано? Ви б не переписували IIS або Apache, тому що вам потрібен веб-сайт, тож навіщо реалізовувати алгоритм QuickSort або об’єкт червоного чорного дерева, коли доступно кілька чудових реалізацій?
• Вільні інтерфейси - уздовж одних і тих же ліній може бути алгоритм, який фільтрує та сортує записи. Це швидко, але, мабуть, не дуже читабельно; ваш молодший розробник зайняв би день лише для того, щоб зрозуміти це, не кажучи вже про те, щоб зробити хірургічну зміну, необхідну для сортування додаткового поля в об’єкті запису. Натомість бібліотеки на кшталт Linq замінюють багато дуже потворних, часто крихких кодів однією або двома рядками викликів, що настроюються, щоб перетворити список об'єктів у відфільтровані, відсортовані, прогнозовані об'єкти.

Мені здається, що ви займаєтесь ІТ, а не CS, і це не повинно означати, що CS мертвий. CS не мертвий - це лише те, що більшість робочих місць є в розробці програмного забезпечення. Оскільки більшість студентів з КС навчаються програмувати, вони, як правило, наймаються як програмісти, а не як інформатики. Завдання з інформатики є незначною порівняно з роботою з програмування. Ви навіть можете робити складний додаток, використовуючи методики інформатики, але на мою думку (і мені не подобаються відповіді думок, оскільки вони суб'єктивні), це потрапляє в інженерний табір, ніж в табір вчених.

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

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

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

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

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

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

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

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

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

Це не означає, що інформатика є мертвою - є ще більше алгоритмів дослідження, і люди проводять дослідження на них. Це, однак, означає, що більшість досліджень є більш спеціалізованими, і вони, ймовірно, стосуються досить спеціалізованих областей. Ймовірно, існує ще більший «розрив» між здобуттям та застосуванням знань. Свого часу ви з'ясували кращий спосіб сортування в процесі написання програми сортування, і це було записано в реальний код майже відразу. Зараз багато інформатики присвячено таким речам, як використання нескінченної кількості процесорів - що, мабуть, стане в нагоді колись, але навіть примітивні племена не вважатимуть подвійні ядра на моєму комп’ютері як "багато" ... :-)

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

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

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

Я думаю, що різниця починає з’являтися, коли з’являються нові проблеми чи парадигми або коли «плескати їх разом» недостатньо добре. Хто будує нові рамки чи мови? Хто сідає і забиває деталі нового фізичного двигуна? Хто використовує теорію графіків / перетворення графіків, щоб викреслити кілька циклів за ітерацію продуктивності з алгоритму?

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

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

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

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

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

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

Ви просто не зрозуміли проблеми. Проблема не в тому, щоб досягти максимальної продуктивності - це отримання достатньої продуктивності, щоб ваш додаток був чуйним і досить швидким. Навчитися програмувати - це вирішення проблеми за найменшу суму грошей.

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

Ну, мертвий чи ні - це дискусійний!

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

Напруга на більшій продуктивності за менший час. (Подумайте про комерціалізацію сільськогосподарських культур / продовольства; швидше та більше зростання з меншими витратами). Те саме відбувається в світі технологій (наступна нова ідея).

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

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

У житті завжди є компроміс. Ви можете знайти роботу, яка платить менше, де у вас є весь час та увага. Або ви вирішили плавати разом з рештою за кращу оплату і ігнорувати речі, які не є ідеальними. Чим швидше ця реалізація зануриться у вас, тим ви зможете перейти до реального світу. Я не кажу, що ви повинні ігнорувати якість та елегантність, але знати динаміку. Ти станеш щасливішим :)

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

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

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