Зачем изучать computer science? Кому это надо? Тысячи программистов прекрасно программируют каждый день без всяких теорий.

МЕНЮ


Искусственный интеллект
Поиск
Регистрация на сайте
Помощь проекту
Архив новостей

ТЕМЫ


Новости ИИРазработка ИИВнедрение ИИРабота разума и сознаниеМодель мозгаРобототехника, БПЛАТрансгуманизмОбработка текстаТеория эволюцииДополненная реальностьЖелезоКиберугрозыНаучный мирИТ индустрияРазработка ПОТеория информацииМатематикаЦифровая экономика

Авторизация



RSS


RSS новости


2021-04-08 01:46

Зачем изучать computer science? Кому это надо? Тысячи программистов прекрасно программируют каждый день без всяких теорий. Почему они должны дополнительно мучиться и изучать какие-то определённые теории, например, теорию типов? Ответ тот же, что и в отношении любой другой теории. Например, зачем кому-то изучать физику? Вы можете прекрасно ездить на машине или играть в футбол и без неё. Тем не менее, лучшие умы во всём научном мире единодушно полагают, что физика настолько важна, что её надо массово преподавать уже в средней школе.

=

Меня регулярно спрашивают, какой фреймворк, язык, архитектуру лучше выбрать для своего "проэкта", и вот такая статистика, что 100% вопрошающих об этом пока что даже не умеют программировать уверенно, не говоря уже о самых азах ОО-проектирования. Я их отлично понимаю — очень уж соблазнительно запилить что-то своё, ну и курсов и учебников сегодня сотни по любым технологиям, как быстро написать дота-киллер или AI-генератор котиков. А вот книг о том, как же правильно программировать и как правильно проектировать, вы насчитаете от силы на пальцах одной руки. Почему, понятно: знакомый продал курс "как быстро разработать игру, почти не умея программировать", в каком-то очередном game maker-e, на 700 тысяч рублей за один месяц. А вот объяснить заранее, насколько важен прежде всего фундамент и computer science, ну наверное просто нереально, пока человек не наглотается пыли от своих проэктов по самое не могу )))

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

Не умея уверенно программировать в плане универсального навыка, не понимая основ объектно-ориентированного проектирования, что можно вообще выдать? В 80% случаев проэкт уже на первом десятке тысяч строк запутается окончательно, и аффтор его забросит; в 20% на выходе выкатится что-то жутко забагованное и тормозящее уже на 10 пользователях в онлайне.

Более того, тут даже невозможно сказать, что это положительный опыт.

Нет, когда делаешь кривой проект кривым подходом, то "учишься" вот ровно этому: как говнокодить говнопроекты, и всё. Это путь не вверх, а в даун.

Например, в Оксфорде на первом же курсе студентов сразу принуждают программировать на Haskell — сразу же прививается и правильное мышление, и правильный стиль, и много других правильностей. Почему же повсеместно в мэйнстриме учат с нуля императивщине — Java, Python и т. д.? Потому, что Haskell просто никто не будет покупать, потому что на практике он почти нигде не применяется (ну, "нигде" конечно в смысле отстойных проектов типа интернет-магазинов :). А абстрактные рассуждения о пользе хаскеля для сильного мышления, понятно, просто всеми пропускаются мимо ушей как надоедливая реклама.

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

=

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

Ха-ха, неа :)

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

Как говорится, если в школе не учил физику, то твоя жизнь будет полна магии и волшебства )))

Детский сад штаны на лямках.

=

Так вот, возвращаясь к пользе computer science. Один из аргументов заключается в том, что математическая теория даёт гораздо большую степень точности, нежели программистам бывает достаточно в большинстве случаев на глазок :) Ну, да, им-то самим конечно достаточно, а вот заказчикам совсем не достаточно их "качества" — оплачивать 70% рабочего времени, которые уходит на поиск и фиксы багов.

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

Программная инженерия, накопившая огромный печальный опыт и статистику катастрофических последствий создания программ самоделкиными на коленках, десятилетиями руками и ногами голосует за научный подход к разработке — хотя и не очень результативно. Я писал уже не раз, что пока в мире не случится эпического сбоя софта, который повлечёт гибель сотен человек (хорошо бы конечно, чтобы без этого таки обошлось), массового принудительного введения промышленных стандартов качества разработки не случится. А ведь давно есть например хорошие стандарты в этом плане, типа ISO или CMM…

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

=

Другой аргумент заключается в том, что теория обеспечивает лучшее понимание процесса разработки. Когда-то создание самолётов было своего рода искусством (как пресловутые братья Райт запускали конструкцию в небо, ждали когда она развалится, и начинали по новой – точно как программисты :), но постепенно, с развитием соответствующих математических теорий, оно превратилось в науку.

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

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

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

=

Так вот, я придумал, каким должен быть курс встраивания (по научному!) в свою голову абстрактной вычислительной машинки, обеспечивающей сильное мышление разработчика. Ну, как придумал – сенсей мне подсказал несколько крутых курсов универов Северной Америки по этой темке, откуда удалось к счастью выудить практически полные содержания их курсов и пару учебников ))) Причём прям свежачок 2021.

Сюда входят темы, которые часто называются "методология программирования", "наука программирования", "логика программирования", "теория программирования", "формальные методы

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

Хорошая теория помогает нам писать точные спецификации и проектировать программы, исполнение которых, по всей видимости, будет удовлетворять этим спецификациям. Самая первая полезная "прикладная" теория для программистов — это так называемая логика Хоара. Кто проходил мои курсы по ООАП, немного познакомился с ней на практике — как правильно проектировать классы с использованием пред- и пост-условий. Но теперь мы подойдём более формально и поглубже, через понятие спецификации как пары предикатов. Близко к Хоару и аксиоматическая семантика Дейкстры, основанная на понятии слабейшего предусловия, которая потом была развита в логике высшего порядка Ральфа Бэка (Refinement Calculus). Ну и Венский метод разработки, классика ещё из 1970-х годов от IBM (там тоже используется пара предикатов, только второй предикат — это отношение).

Не волнуйтесь, мы будем использовать гораздо более простой, но не менее мощный метод :) Я уже говорил, что теперь стараюсь в курсах исключать всю математику и оставлять вообще минимум теории: будем изучать только, всеми любимое "а что это мне даст на практике?" )))

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

Ну а я будут ориентироваться на рядовых программистов, которым таки нужны подсказки :)

=

Мы же будем использовать совсем простую теорию, основанную на хорошо вам знакомых булевых выражениях (операции над логическими значениями). Refinement calculus — это типы, уточнённые предикатами, менее общие, нежели полные зависимые типы, поэтому пруф-термы достаточно легко автоматически выводятся, и вот ручная практика в этом ооочень полезна в плане глубинного понимания логики своего кода. Я уже начал понемногу переносить в курс по функциональному программированию доп.темку по типам, уточнённым предикатами, на F*, летом точно будет доступно бесплатно всем, кто прошёл курс по ФП.

Ну а в плане "что это даст на практике" из теории тут достаточно будет понять обычную импликацию :)

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

Сегодня в качестве альтернативного "механического" способа предлагаются так называемые модел-чекеры (почему этот подход не рекомендуется программистам к изучению, я рассказывал тут: https://vk.com/wall-152484379_3376 ).

которые доказывают корректность, пытаясь охватить все возможные варианты входных данных. Их сильная сторона — удобство для полной автоматизации, и сейчас они справляются с пространством объёмом около 10^60 состояний. Вроде бы круто — но это 2^200, то есть три 64-разрядные переменные в программе становятся пределом :) Поэтому, если у вас в проекте больше трёх переменных (ну хорошо, больше шести 32-разрядных абстракций :), то проверки моделей вам не помогут, корректность (сохранение нужных свойств у этих абстракций) придётся доказывать вручную — как, на курсе будет рассказано. Он ни в коем случае не замена, а наоборот, отличное дополнение к циклу курсов по парадигмам программирования: кстати, очередной курс по плану про декларативную модель программирования (которая порождает и функциональную, и императивную, и ОО-модели) — десятки фундаментальных фишек/паттернов, как правильно писать код (о некоторых вы в лучшем случае догадывались интуитивно, а мы разберём, какова их научная основа, ну и как их применять на практике конечно, множество примеров на Julia будет), я уже на 45% выложил на учебный сервер; этому почти нигде не учат.

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

Или даже так:

"Computer Science: что это вам даст на практике?"


Источник: vk.com

Комментарии: