Проблема не в количестве, а в качестве. Один плохой программист сознаст работу для десятка других программистов.
Если бы выпускаемые программисты владели технологиями, обеспецивающими надежность и упрощающие поддержку - языками с развитыми системами типов, ФП, формальная верификация, их требовалось бы гораздо меньше. А для этого всего нужна математика.
Все можно применять ни чего не зная. Но зная можно применять эффективнее.
Теория категорий полезна в первую очередь для понимания систем типов. Так же категорный подход полезен при декомпозиции задач. При этом надо понимать, что стрелки - не обязательно функции. Это может быть и наследование, и передача данных по конвееру. ТК учит находить общие структуры в различных системах.
Матанализ - не вся математика. Линейная алгебра, общая алгебра, теория категорий и основания математики для программистов важнее. Сам по себе анализ важен в вычислительной математики и машинном обучении. Не связанные с этими областями программисты без матана хуже не станут. А вот теория категорий полезна будет всем.
Хотя тервер и статистику без матанализа изучать странно, а они в анализе данных и машинном обучении нужны.
Это явно ирония.
Во первых он уже постил на твиттер посты с не всеми понимаемой иронией.
Во второых - он сам математик и у него есть программистки-ориентированные лекции по математике: Теория категорий.
devalone, Даже фронтендер может получать пользу от знания математики. Например, в Elm, который позволяет быстро и надежно разрабатывать UI, активно используются алгебраические типы и композиции функций - понять эти концепции гораздо проще, если знаком с теорией множеств (а лучше с теорией категорий).
Наследование в ООП хорошо присывается теорией категорий. То есть знакомому с необходимой математикой можно объяснить отличие виртуального и невиртуального наследования в C++ одной фразой: "для виртуального наследование 'ромбик' является коммутативной диаграммой, а для невиртуального - нет".
Алгебраические типы данных, позволяющие писать значительно более чистый код, чем обычные типы, хорошо описывается теорийе множеств (еще лучше теориями категорий и типов, но они все-же выходят за рамки школьной программы).
Регулярные выражения связаны с формальными грамматиками и конечными автоматими. Конечные автоматы в программировании ценны и сами по себе, а для их анализа полезно знать их связь с регулярными грамматиками.
Сложность алгоритмов во многом базируется на комбинаторике.
Деревянко Александр, ФП вообще то не о том, что есть, а о том, чего нет или ограничено и чем удобно пользоваться за счет избавления от лишнего.
Языки, дизайн которых (и языка, и библиотек ) построен на операции присваивания ни как не могут считаться функциональными. Это относится не только к C, но и к Common Lisp, где, в отличие от Scheme, разрушающее присваивание очень важно.
В чем проблема понять идею множества, понятие функции, предиката, операций объединения, пересечения, произведения и суммы?
Я не утверждаю, что надо вводить множества аксиоматически и рассмативать акиому выбора и другие сложные моменты, достаточно элементарных понятий.
Common Lisp я бы не назвал функциональным. Там очень большое значение имеет мутабельность.
Для F# еще есть транслятор в джаваскрипт.
Haskell сложный скорее для имеющих опыт императивного программирования - приходится все делать совсем подругому. Для совсем новичков он будет легче. То же можно сказать и про Prolog.
Scala - один из самых сложных языков. Браться за него всерьез стоит только после изучения Haskell, а еще не помешает C++. Еще для изучения ФП он плохо подходит из-за непоследовательности, вызванной необходимостью работы на JVM, которая делалась не под функциональные языки.
Хотя, будучи знамомым с Java и ее экосистемой, можно быстро начать программировать на Scala, в том числе и в реальных проектах. Но не используя большую часть ее возможностей, особенно относящихся в ФП.
Зарабатывал сисадминством, снятием защиты от копирования, низкоуровневым программированием, web-программированием. Но ко всему этому интерес потерял. Что я делал не так?
Если не хватает шифрования и производительности, то криптографию проще и надежней реализовать отдельным модулем со своим процессором и воспользоваться готовой библиотекой.
Реверс-инжиниринг, конечно, ассемблер требует. Но рынок для этого не очень большой и явно не для начинающих.
> Сначала научись писать программы, а потом ты с удивлением обнаружишь, что знаешь все языки программирования
Сколько я видел людей, успешно программирующих на языках от C с ассемблером до питона с пхп, которые при попытке написать даже что-то простое на Haskell или Prolog впадают в ступор.
Если бы выпускаемые программисты владели технологиями, обеспецивающими надежность и упрощающие поддержку - языками с развитыми системами типов, ФП, формальная верификация, их требовалось бы гораздо меньше. А для этого всего нужна математика.