> Декларативное мышление во многом ближе к
>повседневному человеческому мышлению, чем алгоритмическое. Было бы оно ближе, появилось бы раньше :) На самом деле не ближе. Человеку свойственно создавать алгоритмы. И было свойственно еще до появления математики в современном понимании. Пример? Кулинарные рецепты, религиозные обряды. Сделай то и то, и получишь вот это. Это алгоритмическое мышление.
>>Самый просто подход в этом случае -- процедурный.
>Самый простой для Вас, возможно, в связи с Вашей (без знака плюс-минус)
>парадигмой мышления (о чем и речь в статье).
Ну, как можно (мне кажется) понять из остального моего поста, мне таки ближе ООП. А про процедурность это я из собственного опыта и наблюдения за начинающими говорю.
>>Более легкий в сопровождении -- объектный. И ООП как раз ближе к
>>реальному миру, чем к железу.
>Только не нужно ООП противопоставлять функциональному подходу, Вы это напрямую не сделали,
>конечно, но косвенно так получилось.
Секундочку. Я не противопоставляю. Я говорю, что для решения задач, связанных с моделированием нестрогих процессов реального мира больше подходит ООП. Для моделирования строгих процессов (расчет деформации при ударе, например) больше подойдет ФЯ.
>>А смоделировать работу предприятия торговли, например, на функциональных
>>языках -- врагу не пожелаешь.
>Почему??? Вот уж где сплошная декларативность, при минимуме алгоритмов.
Где? О_О Там столько возможных вариантов ветвления, что памяти, основанной на состоянии атомов всей вселенной не хватит для реализации требуемых вычислений :) При этом некоторые параметры как правило не определены или могут меняться в широких пределах.
>>Хе, широко распространенное в узких кругах. ФЯ короче, пока на них пишутся
>>алгоритмы функционального поведения. Это скорее синтетические алгоритмы, мир на много сложнее.
>Ну нет, программы на ФЯ короче практически всегда. Возьмите вон xmonad -
>оконный менеджер на Хаскелле, 500 строк. Ну или контрпример приведите, по
>возможности общего характера, где ФЯ были бы менее эффективны чем ИЯ
>(допускаю что приведете, но уверен что не сходу..)
xmonad -- это один из самых неудачных примеров программирования на ФЯ. Кроме того, оконный менеджер это скорее синтетический алгоритм. В смысле узко определенный круг задач. Да еще и возможности несколько недотягивают до современного уровня. Или не слабо дописать xmonad до полноценной замены компизу? ;) Шутка. Сходу, Вы правы, не приведу пример. Не потому, что лень думать, а потому, что не использовал ФЯ в реальных задачах. У меня небыло такой необходимости. Хотя функциональную парадигму в обработке реакций пользователя в интерфейсах я использую. Там она хорошо ложится.
>>Чушь, простите. ООП кушает больше, чем ФОП.
>Во-первых, опять же - не надо противопоставлять ООП и ФОП. Во-вторых, почему
>больше? Обоснуйте. ФОП со своими списками да рекурсиями естественно жрет больше
>(памяти).
В ФОП совсем не обязательно использовать списки. Это кажется начинание лиспа было. И, по большому счету, является протезом для решения более широкого круга задач. Рекурсия используется, но при правильном подходе ее глубина не сильно важна. По сравнению с этим виртуальные функции, шаблоны, рефлекшены и исключения поглатят больше. Хотя, если на ФЯ писать базы данных, то скорее всего в битве у кого длинее стек победят функционалы :)
>
>>Функциональная парадигма изначально заложена во всех языках программирования, ибо она лежит в
>>основе любой железки с логикой.
>Ничего себе. А я думал императивная. Вы уверены, что понимаете, что такое
>функциональная парадигма?
Уверен. Императивная парадигма там тоже есть. И особо удивляться не надо. Их там две :)
Когда мы меняем регистры -- это императивно. Когда мы обращаемся к внешнему оборудованию -- это функционально. Ибо внешнее оборудование никак не влияет на состояние АЛУ.
>>Проблем у С++ крайне не много. [...]
>>от С достались функции и макросы, от которых следовало бы отказаться [...]
>Отказаться от функций?
Что так удивляет? В Java нет функций. Есть методы. И в их пользу надо бы отказатиься. Ну, это конечно только чтобы добиться более строгого соблюдения принципов ООП.
>Да у него полно проблем, связанных с наследственностью. Ну чтоб далеко не
>ходить - убогая модульная система.
Это далего не бесспорный минус. Я бы сказал, что это скорее плюс.
>>[...] отсутствие асинхронных вызовов в самом языке. [...]
>>[...] невозможности прозрачно средствами языка создавать
>>многопоточные и распределенные системы.
>Вот уж за что мне не пришло бы в голову критиковать С++)
Ну, конечно, каждому свое, но в целом это сдерживает переносимость программ на С++ между платформами в современных условиях.
>>И над последними двумя наши люди (ну, вы понимаете) уже работают :)
>Что тут скажешь.. верной дорогой идете, товарищи)
>Да, кстати, ФЯ и параллелятся лучше (ну, вы понимаете)
Ещебы, паралеллизм у ФОП в крови.
>>Это как раз про "Очень-очень сложный язык". МН реализовано не коряво, а
>>изящно :) Просто это сложно понять.
>Практически невозможно) То-то оно и используется повсеместно.
Ни с чем не путаете? Множественность интерфейсов и множественное наследование хоть и родственнеки, но все же разные вещи. Я вот так сходу, даже подумав, не могу вспомнить ни одну широко известную библиотеку для С++, которая бы использовала множественное наследование.
