угу, мне тоже как студенту, у кого курс вышки уже пройден, интересно знать, чему нас не учили или учили плохо :)
Вид для печати
На самом деле ООП еще дальше от низкоуровневого программирования, чем спагетти стайл (так шутя называют функциональное программирование). И гораздо непроизводительнее. На том же С или Php при помощи ФП можно писать такие сорцы, которые будут пережиматься в машинный код не хуже, чем если бы его писали на каком то макроасме (от дистрибутива компилятора конечно зависит многое тоже). ООП создан в принципе для улучшения понимания программы и кроссконстракшна.
Что касается разделов математики, требуемых для понимания Хаскеля: спецы рекомендуют изучить практически ВЕСЬ матанал. Это меня и напрягло :). Все таки в программировании помимо математики имеется еще и логика, и порой ее бывает программисту достаточно. А математика на деле вся сводится к разработке алгоритма подсчета очков в игре )))). Лично мне много лет назад по настоящему пригодились только таблицы умножения на 2 и на 8 (но многое изменилось.)
Еще Хаскель подтолкнул к мысли, что компьютерщики решили отменить девиз 90х - "Программирование доступное каждому", воззрев на деяния рук ламерских в интернетах:v2_dizzy_roll:
Большая часть сказанного в посте верно, но эти цитируемые положения я уточнил бы:
ООП создан для распила бюджетов заказчиков, код на выходе получается не для понимания, а для увеличения количества багов и часов на разработку и отладку. ФП тем и отличается от всех прочих подходов, что отладка (не кода а описания алгоритма, т.к. ФП это не кодирование, а именно описание самого алгоритма задачи на языке математики) идет в процессе разработки, а не тогда когда программист отдал на тестирование свой код и уже забыл всю логику в нем и по прошествии времени уже и сам с ходу не может в нем разобраться, таковы реалии ООП. Языки ФП - языки математики - понятны любому математику-программисту. Наиболее значимые разделы математики это не логика и не матан, а лямбда-исчисление, часть комбинаторики и новая тенденция важная для задач искусственного интеллекта - теория нечетких множеств. Все другие разделы математики можно оставить теоретикам, в том числе и всю матлогику (т.к. логика без вероятностных функций не подходит для решения сложных задач, к примеру ИИ, и программы на выходе получаются убогими и тупыми).
Программирование мне интуитивно казалось неразрывно с математикой, но увы, столкнувшись в двух лучших вузах страны с действительностью, мало что полезного включено в курс вышки для программирования, разве что численные методы и задачи математического программирования, а остальное всё годно лишь для разминки мозгов и мало пригодно для практики ФП.
Само программирование никогда не было предназначено для непосвященных. Но если рассматривать процесс программирования не как процесс кодирования (Си, Си++, php, ruby, ассемблер, SQL, NOSQL), а как процесс описания задачи (Erlang, Haskell, Lisp, Prolog...) то он лишь доступнее станет для большего количества специалистов, владеющих языком математики, а не особенностями архитектуры машины, синтаксиса нового модного языка или парадигмы, и эти специалисты смогут больше времени уделить выбору и оттачиванию описания алгоритма решения задачи, а не его кодированию и тестированию.
Мне, как программисту они, так же, как и язык высшей математики - не понятен. Вернее, понятен, если разбираться, но не близок. И потом, разве единственаня цель, к которой надо стремиться - это создание ИИ?
К слову сказать, на текущем уровне развития человечества, создание ИИ, имхо, невозможно. Все, что создано, это даже не столь элементы искусственного интеллекта, а скорее его имитация. Я занимался системами распознавания речи и смежными задачами, и плохо представляю, как бы удалось все это реализовать на ФП. Тогда как на обычном Си и ассемблере любые задачи от простой логики, ступеней ЦОС, и потом уже вероятностных схем, ДП, Витерби и т.д. реализуются на ура.
Нужно различать оптимизацию кода и правильный выбор алготима и совершенствование его описания. В ФП нет места процессу кодирования.
Компилятор, в том числе и языка ФП не сможет и не должен справляться с оптимизаций алгоритма, это творческий процесс для человека, а вот с задачами оптимизации трансляции описания алгоритма в бинарный код, компиляторы и интерпретаторы языков ФП уже справляются блестяще и программисты постоянно совершенствуют трансляторы (в этом можно убедиться если пронаблюдать за выходами новых версий и описаниям изменений).
Самая лучшая оптимизация - это машинно-ориентированная оптимизация алгоритма под возможности конкретной машины. Прямой тому пример те же демки под Спектрум. Никогда бы не было никаких Шоков-мегадемо и иже с ними, если бы сперва поставлен четко оптимизированный математически алгоритм, а потом отдан на откуп любому компилятору. Такое возможно только с учетом знания возможности машины, преобразования алгоритма и адаптация его в соответствие с сильными сторонами конкретного железа, и итоговая реализация уже в наилучшем виде, что и называется алгоритмическо-машинной оптимизацией алгоритма и даже ЗАДАЧИ в одном флаконе.
Нужно сделать выбор или человек будет выпускать неэффективные машины и программы требующие много времени для ремонта и диагностики ошибок, или машины будут все таки помогать человеку и алгоритмы (а не код) их работы будут в раскрытом виде перед специалистом.
На данном этапе, машинно-ориентированный код нужно отдать компиляторам и интерпретаторам и специалистам (компиляторщикам) работающим с теми архитектурами, что имеются в наличии, а также наладить с этими специалистами обратную свять, чтобы архитектуры машин менялись к лучшему - в сторону более оптимальной архитектуры для поддержки ФП. Красивые и эффективные программы на обычных языках (кодирования) большие в объеме, сложные, и очень тяжелы в поддержке и развитии.
Но даже на тех архитектурах что есть, программы на языках ФП работают быстрее и лучше любых незграмотных программ на обычных языках, т.к. вносить случайные ошибки в программу на языке ФП сложнее.
Пробовал я егланг, хаскель, лисп. Я писал компилятор пролога, который уделал swiprolog и visaul prolog по производительности.
В том то и проблема этих языков, что они слишком высокоуровневые. Вы должны изучить специальный язык, что бы описать задачу, для решения которой компилятор сам составит программу. И не факт, что хорошо напишет. В erlang нет команды, оптимизируй эту функцию еще и еще раз.
А повсеместное ООП - это во первых зло, а во вторых народ сходит с ума. Он пишет ООП только лишь ради ООП, а не упрощения программы.
---------- Post added at 12:57 ---------- Previous post was at 12:54 ----------
Erlang - это все равно набор низкоуровневых алгоритмов, которые придумал создатель языка.
Вообще, у любого языка главное качество - быть простым. Именно поэтому рулят JavaScript, PHP в большей степени, чем C# и Java.
А такие монстры как Erlang курят в сторонке. Ибо программисты стоят дорого, а замена программиста в проекте вообще маловероятна.
---------- Post added at 12:59 ---------- Previous post was at 12:57 ----------
А еще с отладкой туго у этих языков. Строки программы могут выполняться в произвольном порядке, рекурсивно, что то может никогда не выполняться, а это рвет мозг программиста на куски.