чи важливе кодування? [зачинено]

Чи важливо кодування, щоб бути хорошим у галузі інформатики? Чи варто реалізовувати алгоритм, щоб його добре знати?

Я пам'ятаю ідіому одного професора, що " я ніколи не кодую"

Ви не будете дійсно знати алгоритм добре до тих пір , поки його код.

Кодування не важливо для вашого професора, але вам потрібно пам’ятати, що він не платить робити речі. Йому платять ЗА РЕЧЕННЯ (і ЗАПИСИ речі.)

Я колишній професор математики, тому добре розумію цю динаміку.

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

Інформатика - це не більше комп’ютерів, а астрономія - телескопи

^{- Едсгер Дійкстра}

Я схильний погоджуватися.

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

Щоб провести аналогію: це трохи схоже на запитання, чи повинен кожен учений з ракет НАСА літати в космосі, щоб бути «добрим ученим-ракетом». Звичайно, ні. Бути космонавтом - частина космічної галузі польотів, і це дуже практична частина, але це не означає, що вчені-наземні не так важливі по-своєму.

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

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

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

Однією з великих проблем в галузі інформатики є те, що їм часто доводиться знаходити рішення математичних задач, які мають мало корисності у вирішенні проблем сьогоднішнього програмування. Навіть якби вони зашифрували рішення, його ніхто не зміг би використати. Подумайте про теорію цифрової обробки сигналів. Його винайшли такі люди, як Фур'є, Гільберт і Шеннон, але застосування для комп'ютеризованих проблем з DSP не було широко можливим приблизно 20 років тому.

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

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

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

Залежить від підполя, в якому знаходиться професор.

Хто-небудь компетентний в числовому аналізі, мабуть, фортранський свист. Будь-який професор AI буде кодувати в Ліспі чи Пролозі чи щось подібне.

У деяких більш математичних областях насправді не потрібно кодувати. Я все одно буду дотиком підозрілим.

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

Я б сказав "Логіка важлива"

Ви можете піти лише від розуміння теорії, але я завжди знаходив, що я розумів алгоритми та такі 1000x краще після їх кодування (наприклад, Bubble Sort vs. Quicksort, чудово знати Big-O, але бачити це на практиці з великими даними -набір дає певну оцінку реального світу для вимірювання складності обчислювальної техніки).

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

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

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

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

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

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

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

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

Але для переважної більшості відмови від кодування абсолютно немає користі.

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

Єдиним класом CS, який я брав із абсолютно не програмуванням, була теорія. Я думаю, що там багато фізиків, які кажуть: "Я ніколи не експериментую", але вони, мабуть, також ті, хто каже: "Я ніколи нічого не відкриваю". І я був би здивований, якщо їм все одно.

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

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

Добре, я думаю, що люди, які не переймаються поняттями, як ті програмісти, які використовують винятки як звичайний робочий процес у своїх програмах. Вони знають, ЯК, але дійсно не отримують ЧОМУ.

У мене є ще одна ідіома для вашого професора:

Ті, хто вміє, роблять, ті, хто не може, навчати.

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