>>Было бы оно ближе, появилось бы раньше :)
>
>А я ошибусь, если скажу что lisp - старейший из "живых" языков
>программирования? (точно не уверен, но сдается мне так оно и есть) http://people.ku.edu/~nkinners/LangList/Extras/famous.htm
Я в истории не силен, но судя по всему, все-таки фортран старее.
Живость его можно подтвердить в любом отечественном НИИ.
[.. Проскипано без возражений ..]
>>Где? О_О Там столько возможных вариантов ветвления, что памяти, основанной на состоянии
>>атомов всей вселенной не хватит для реализации требуемых вычислений :) При
>>этом некоторые параметры как правило не определены или могут меняться в
>>широких пределах.
>
>Не понял, почему для ИЯ хватит а для ФЯ нет, если к
>тому же ниже утверждается, что ИЯ жрет больше. Причем тут ветвление?
>замените ветвление на сопоставление с образцом, и получите декларацию.
Во! Я кажется начинаю понимать суть проблемы :) Вы пытаетесь применить ФОП ко всему подряд. Это и вызывает утверждение, что ФЯ потребляет больше ресурсов. Да, на определенном классе задач, для которых ФЯ не предназначены, ресурсы будут потребляться сильно. Зато на своем поле им нет равных (ИИ, например, проще всего реализовывать на ФЯ)
>Вот встречный вопрос - где там алгоритмы. Сплошные данные и декларации.
Алгоритмы? Хм.. Ну что-нибудь алгебраическое... Алгоритм расчета продажной цены товара исходя из себестоимости, затрат на логистику, комиссии менеджеру, супсидирования рекламных компаний, колебаний курса валюты и репутации партнера. А теперь нужна вилка "от" и "до" при известной себестоимости. И еще хочу, чтобы любой из этих параметров можно было по отдельности задавать или не задавать. А еще чтобы вилка вычислялась с учетом прошлых продаж человека, который сейчас заполняет заявку. А еще хочу, чтобы опционально учитывалась или не учитывалась динамика роста каждого из этих параметров.
Это из жизни. Было реализовано. Было не просто, особенно с удовлетворением постоянно растущих "хочу".
Просто на ФЯ каждое дополнительное "хочу" прибавляет расход памяти, не сопоставимый с решаемой задачей. Кроме того, потребуется несопоставимо больше переделывать с каждым "хочу" (хотя здесь могу ошибаться, не силен). И уж точно последнее "хочу график динамики продаж в реальном времени" убивает всю идею использования ФЯ, ибо циклы не предусмотренны парадигмой. А бесконечный цикл, реализованный рекурсией, как не сложно догадаться убивает машину, на которой запускается.
>Алгебра списков - протез? Ну и ну. А что тогда STL?)
Именно протез. Переход из одномерного пространства в n-мерное. Это как комплексные числа. Вроде они есть, но это существо виртуальное.
А STL -- плод весьма больного воображения наших соотечественников. Причем, не первый, который оказался весьма удачным. Вообще, идеалогия шаблонов в принципе это попытка уйти от строгой типизации данных, сохранив ее. Мне кажется, удачная попытка для первого раза.
> И - все-таки, для ФЯ это основной тип данных.
Бесспорно. Иначе на них не решить нематематических задач. И математические не все.
>А вот упомянутые шаблоны - да, протез, причем на редкость кривой) да
>и то как они что-то поглотят, они ж компайл-тайм.
Они компил-тайм в текущей реализации. Стандарт не накладывает никаких ограничений на этот счет. Стандарт вообще не заставляет компилировать код на С++ в бинарный. Стандарт определяет только поведение написанной программы.
Если бездумно пользоваться шаблонами, то минимальный код превращается в кучу бинарного мусора, делающего одно и то же со смежными типами данных. Так что шаблон шаблону рознь.
Ну и раз уж зашла речь о кривизне, можно поинтересоваться, а что Вы посоветуете использовать вместо шаблонов? И вообще, для начала давайте определимся, понимаете ли Вы всю широту решаемых с помощью шаблонов задач? Вы знаете, что шаблоны могут быть рекурсивными? Вы знаете, что с помощью шаблонов можно вычислить факториал, например (это из книжки про шаблоны)? Я не хочу Вас обидеть, просто у меня складывается ощущение, что мы разговариваем об одном и том же, но стоя с разных сторон одной планеты (- Это вы там ходите вверх ногами! - Нет! У нас небо сверху, а вы ходите ногами к нашим ногам, значит у вас небо снизу!).
Просто я не считаю себя гуру функционального программирования. Я его изучал как хобби. Основные мысли мне ясны, я ими проникся и примитивные вещи иногда использую в практической работе. Зато С++ мой родной язык, о котором я думал много плохого, пока его изучал, но когда привык к мышлению в стиле ООП стало легко и просто. И многих вещей из С++ мне сейчас нехватает, ибо занимаюсь другими вещами.
>Глубина рекурсии, естественно, очень важна, другое дело что при правильном подходе она
>в цикл разворачивается компилятором и рекурсии не будет.
Будем считать, что как защитник ФОП Вы сморозили глупость :) Ибо как защитник Вы должны отстаивать идеалы ФОП, а не перекладывать на компилятор более оптимальную реализацию на процедурном языке.
Если все-таки это нетак, так чего бы сразу не написать цикл и не ломать голову?
>Хм, нет. Это все императивно, это строго определенная последовательность действий с передачей
>управления от одного к другому. Никакой функциональной парадигмы там и в
>помине нет. Сохранение состояния тут роли не играет.
Нету там передачи управления, но спорить не буду. В моем понимании основные принципы функциональности -- 1. Невмешательство в аргументы (выполнение функции не влияет на аргументы и не меняет состояние глобальных объектов, которых вообще нет). 2. Законченность действий (функция, будучи вызванной всегда вернет результат, причем этот результат будет зависить только от параметров самой функции, т.е. при одинаковых аргументах результат будет одинаковым).
Вот, пожалуй, две основные вещи, которые отличают процедурный подход к программированию от функционального. Сразу, чтобы небыло флейма, это не все, а только основные. И это не парадигмы, а формальные отличия.
>А С++ - не полностью ООП-ориентированный язык, он, как тут справедливо писали,
>претендует на универсальность. Поэтому там подобное неуместно.
А вот и зря. Ему было бы легче.
> Зачем делать из него
>яву? А то пусть там все типы данных, включая примитивные, объектными
>будут, как в smalltalk. Почему б нет. Для более строгого соблюдения.
Я вот не пойму, это сарказм? Если да, то напрасно. Вы не поверите, но во многих библиотеках (больших и толстых) определены классы для всех типов данных, включая примитивные. Но это не для строгого соблюдения, а для удобства. Я понимаю, что для человека, который не участвовал в больших проектах, написанных на С++ или другом ООЯ это тяжело понят, но поверьте мне на слово (или спросите у знающих людей, которым Вы доверяете), оно правда бывает очень нужно. Особенно с числовыми типами.
>[оверквотинг удален]
>>родственнеки, но все же разные вещи. Я вот так сходу, даже
>>подумав, не могу вспомнить ни одну широко известную библиотеку для С++,
>>которая бы использовала множественное наследование.
>Так в ту фразу очевидный сарказм был заложен) Потому и не используется,
>что кривизна. И видимо совсем уж полная кривизна, потому что страсть
>зеалотов С++ к использованию кривых инструментов для создания головоломок - притча
>во языцех)
>
>В отличие от множественного наследования интерфейсов, да. Удобный механизм, и применяется в
>разных языках без особых проблем.
:) Можно я вместо ответа на эту часть личный вопрос задам? Можете не отвечать, но мне просто интересно. Вы ведь не участвовали в крупных коммерческих проектах на С++. Причем именно на С++, это важно. Соответственно Вы не могли использовать множественное наследование в полную силу на протяжении долгого времени и посмотреть на чужой код, в котором реализовано это множественное наследование. Исходя из этого, и того, что Вы утверждаете, что МН и шаблоны в С++ реализованы криво (я верю, что это только из-за недостатка опыта) и так хорошо ориентируетесь в ФЯ и ФОП в частности могу предположить два варианта: либо Вы научный работник (аспирант, например), либо инженер AutoCAD. Я прав?
