о развитии ЯП

>Разве в моих рассуждениях есть какой-то намёк на то, что я считаю преимуществом длинный но глючный код?

Ну, исходя из того, что Вы считает рефакторинг "пустопорожним занятием", такой вывод сделать несложно...

>А зачем равняться на венду?

Я на неё не равняюсь. Наоборот я привёл её, как пример кода, в котором рефакторинг не проводился...

>Есть какие-нибудь сомнения что грамотно построеный процедурный код намного легче использовать чем ООП? Или что процедурный код намного легче грамотно спроектировать чем ООП?

Возможно я немного категорично высказался - всё сильно зависит от задачи. Но в общем случае - да, ООП-код повторно использовать проще, чем функциональный. Это и была одна из причин появления ООП...

>> Разве в моих рассуждениях есть какой-то намёк на то, что я считаю преимуществом длинный но глючный код?

> Ну, исходя из того, что Вы считает рефакторинг "пустопорожним занятием", такой вывод сделать несложно...

А если я скажу что костыль - неудобно, тут же последует вывод что я против ходьбы?

>> А зачем равняться на венду?

> Я на неё не равняюсь. Наоборот я привёл её, как пример кода, в котором рефакторинг не проводился...

Почему бы не привести пример кода, в котором рефакторинг не проводился просто потому что он не нужен?

>> Есть какие-нибудь сомнения что грамотно построеный процедурный код намного легче использовать чем ООП? Или что процедурный код намного легче грамотно спроектировать чем ООП?

> Возможно я немного категорично высказался - всё сильно зависит от задачи. Но в общем случае - да, ООП-код повторно использовать проще, чем функциональный. Это и была одна из причин появления ООП...

Практикой тезис о более лёгком повторном использовании ооп кода вроде бы не очень-то подтверждается... Или ты действительно считаеш, что рефакторить кучю кода проще, нежели чем переписать/добавить функцию-другую?

> ООП-код повторно использовать проще, чем функциональный.

Месье не путает случаем функиональный с процедурным?

> Ты ацтал ат жизни!! В TopGear-е как раз взяли пятерку вазовскую разок, взяли кучку инженеров из Lotus Sports взяли 200 штуки зеленых

В конечном концепт-каре от пятерки остались только замок зажигания и ручка от ручного тормоза...

Всем кому интересна тема C++, Lisp, Smalltalk, рекомендую почитать эту книжку:

http://www.a-vo.com/books/book.php?fn=CppForRealProgrammers_rus.rar

Hint: Это не прямая ссылка на архив. По ссылке описание и линк на закачку.

Книжка на русском в PDF, весит в распакованном виде 1.9Mb. Написана с иронией и сарказмом. Как раз для ЛОРовцев. Асиливается за два-три дня и отлично поднимает настроение. Читать всем холиворщикам независимо от отношения к С++ ;)

> Не нравится вам лично С++ - пишите себе спокойно на чём угодно,

Ну дыкть, и пишем спокойно. Но в наши сердца стучит пепел Клааса и горькие воспоминания о бесцельно загубленной молодости :-)).

> до 1M строк кода

"...но при этом такая фигня получается..." :-))).

>Лисп: Я думаю, что для большинства задач программирования >императивный, и в частности объектно-ориентированный стиль подходит >больше, чем функциональный. Не для 100% задач конечно, но для 95. В >императивном стиле удобнее писать на С++, чем на лиспе.

Лисп не функциональный язык. В нем хорошая поддержка любых императивных конструкций и можно наделать еще сколько хочешь. В С++ же новую конструкцию языка не добавишь (например нечто вроде case), никакие шаблоны тут не помогут, т.к. язык шаблонов не совпадает с самим С++. Если требуется метапрограммирование например вставка какого-то банального результата работы функции в программу, то в С++ надо разводить всякие шаблоны, в Лиспе - это та же самая функция, просто пишешь где надо например #.(factorial 25) и результат просчитывается во время считывания этого выражения ридером и вставляется в код, причем можно сделать так чтобы он вычислялся один раз, а не при каждой перекопиляции этой части кода. Список типов, если посмотреть у того же Александреску - это целая эпопея с переизобретением связных списков на шаблонах. В Лиспе список типов во время компиляции - это такой же список как любой другой во время выполнения программы и с ним сразу работают все функции для работы со списками.

>Производительность - почему некоторые куски емакса всё же написаны >на сях?

Во-первых Си - это естественный язык для бутстрапинга разных систем, Лисп системы не обязательно бутстрапятся с Си. Во-вторых написанные на Сях части Лисп системы могут не являться частью его компилятора, т.е. то что генерит код и сам сгенеренный код могут не включать части написанные на Сях. И вообще, если Си - кроссплатформенный ассемблер, предназначенный для системных вещей, причем тут С++ ? Если часть системы реализована на низкоуровневом языке, глупо настаивать все остальное тоже на нем писать.

Нет никаких принципиальных предпосылок, что Лисп программа должна была быть тормознее С++. Если отключить все проверки, указать где надо типы, то нормальный компилятор сможет сгенерить код не хуже чем с С++. Если погонять SBLC и сравнить дизассемблированный код с MS VC++ 8.0, то видно, что SCBL оптимизирует в сущности до предела, т.е. никаких специфичных для Лиспа моментов не остается, C++ компилер просто имеет лучшую поддержку, всякие там хитрости по оптимизации используются, которые в лисповом компилере тоже бы работали на ура и многое уже реализовано.

Учиться всем премудростям этих костылей надо три года, очень сложно все -- на программы времени не остается. Зато в языке копаться -- очень интересно :-)

>Не используйте raw pointers в С++ (std::auto_ptr, boost::scoped_ptr, >boost::shared_ptr - этого уже более чем достаточно) - и каким бы >большим проект ни был, утечек памяти не будет.

Вот видите, назвали целых три вариации. Значит, скорее всего сталкивались со всеми тремя. Две из них -- из одной библиотеки, значит нужны для разных целей. И что, я еще должен разбираться во всех тонкостях применения каждого варианта? Вот такой C++ весь. Кстати, "библиотека цифровой обработки сигналов" -- элементарная задача для haskell, например.

Лисп простой? Шутить изволите? Чегож в нем простого? Один скобочный синтаксис чего стоит.

>Значит, скорее всего сталкивались со всеми тремя

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

>И что, я еще должен разбираться во всех тонкостях применения каждого варианта?

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

>Вот такой C++ весь

Да. Именно за это его и любят ;)

>Кстати, "библиотека цифровой обработки сигналов" -- элементарная задача для haskell, например.

ну, вот это совершенно необоснованный комментарий. Я упоминал написание этого дела на prolog'е, подчёркивая его неуниверсальность. Или вы умеете скрещивать prolog с haskell'ем ? Конечно, её можно написать на Haskell. А GUI к ней вы тоже будете писать на Haskell ? Это ведь тоже специализированный язык... В С++ есть механизмы решения и первой и второй задачи... Кстати, я бы начал не с Haskell, а с Yorick - там это было бы ещё проще, во всяком случае на период тестирования и отладки алгоритмов. А потом уже писал бы на С++ с использованием Blitz++/MPL etc...

Каждый специализированный язык несомненно лучше для решения своей задачи чем универсальный С++. Но не об этом же речь...

> Лисп простой? Шутить изволите?

А чё сложново то?

> Чегож в нем простого?

Базовых концепций, из которых выводится всё остальное, намного меньше.

> Один скобочный синтаксис чего стоит.

В том числе и скобочный. Если в лиспе ( означяет начяло а ) конец некоей логической структуры, а разделителем последовательностей - пробел, то в с++ используются в разных случяях не только эти же самые (), но и {} ; , [] ? : :: . -> < > Я ничё не пропустил?

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

Почему же в других наречиях такие нагромождения ненужно?

> В данном случае такое разбирательство ведёт к пониманию механизмов работы с памятью, что отнюдь не лишнее - в любом языке эти механизмы есть, просто в некоторых они скрыты.

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

> Или вы умеете скрещивать prolog с haskell'ем ?

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

> А GUI к ней вы тоже будете писать на Haskell ?

Собственно, почему бы и нет? Хотя идея не очень удачная конечно...

> Каждый специализированный язык несомненно лучше для решения своей задачи чем универсальный С++. Но не об этом же речь...

А речь о том, что

> компромисс всегда хуже любой из альтернатив (с) законы Мерфи...

Аффтары с++ пытаюцо предоставить "усреднённое по больнице" наречие, а в лиспе - механизм для создания специализированного для задачи наречия. Оттого С++ и черезмерно усложнён и плох для любой конкретной задачи.

> Базовых концепций, из которых выводится всё остальное, намного меньше.

Ограниченный, красивый набор базовых концепций в лиспе существует только на уровне синтаксиса. Яркий пример - Common Lisp. Как только начинаешь программировать реальные приложения на этом языке отчетливо осознаешь, что платой за относительно простой синтаксис, является необходимость держать в голове кучу различных функций, макросов и специальных форм. Все то, что в других языках обозначалось краткой синтаксической конструкцией здесь имеет склонность превращаться в нечто вроде

(aaaa-bbbb-cccc (xxx-yyyy-zzzz ((a b) (c d))))

Взять хотя бы в качестве примера CLOS. "Простота" это явно не про Common Lisp.

> Если в лиспе ( означяет начяло а ) конец некоей логической структуры, а разделителем последовательностей - пробел, то в с++ используются в разных случяях не только эти же самые (), но и {} ; , [] ? : :: . -> < > Я ничё не пропустил?

Каждый разделитель имеет свое функциональное предназначение. В лиспе для того чтобы получить аналогичное функциональное предназначение надо еще и функцию помнить. Например, аналог {...} в лиспе будет выглядеть примерно так (progn ...), аналог a[i] - (aref a i). Что проще запомнить: несколько специальных символов или названия функций ? Первое по мне так первое гораздо проще. Хотя бы просто исходя из количества символов которые нужно запомнить.

> На лиспе нету никаких траблов заимплементить пролог и решать задачу в терминах пролога

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

> Все то, что в других языках обозначалось краткой синтаксической конструкцией здесь имеет склонность превращаться в нечто вроде

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

> Взять хотя бы в качестве примера CLOS. "Простота" это явно не про Common Lisp.

Что не так с CLOS?

> Каждый разделитель имеет свое функциональное предназначение. В лиспе для того чтобы получить аналогичное функциональное предназначение надо еще и функцию помнить.

И что? Лишних концепций в лиспе всёодно меньше.

> Например, аналог {...} в лиспе будет выглядеть примерно так (progn ...),

Не совсем так. Для (progn ...) аналог {... ; return ы;} ибо есь ещё prog1 и prog2 и другое.

> Что проще запомнить: несколько специальных символов или названия функций ?

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

> Первое по мне так первое гораздо проще. Хотя бы просто исходя из количества символов которые нужно запомнить.

Аха, "щяз трудно найти программиста с хшей паметью" (С) сам знаеш чей. Фактически, сложность поределяется количеством базовых концепций которые нужно понять и усвоить, но никак не длиной мнемоник. А "большее" количество "символов для запоминания" в лиспе компенсируется их большей гибкостью и более плотной адаптацией к терминам, в которых решаецо задачя.

Для большинства случяев достаточно и такого, и в любом случяе имплементить примитивный ли полноценный пролог на лиспе всё-таки луче. И присоединить внешний, готовый, к лиспопроге прикрутить нисколько не сложнее чем к с++шной.

> Аха, "щяз трудно найти программиста с хшей паметью" (С) сам знаеш чей. Фактически, сложность поределяется количеством базовых концепций которые нужно понять и усвоить, но никак не длиной мнемоник. А "большее" количество "символов для запоминания" в лиспе компенсируется их большей гибкостью и более плотной адаптацией к терминам, в которых решаецо задачя.

Запомнить базовых концепций в лиспе нужно столько же сколько и в любом другом языке программирования. А чтобы нормально программировать надо запомнить их даже больше.

Синтаксис тут особой роли не играет. В языке с развитым синтаксисом нужно, естественно, этот синтаксис надо изучить. В лиспе надо изучить его примитивный синтаксис, плюс кучу всяких функций при помощи которых этот примитивный синтаксис фактически доводится до развитого синтаксиса другого языка программирования. Что проще - вопрос.

Основная сложность любого языка заключается в семантике. В лиспе семантика по большей части эквивалента, а то и гораздо сложнее за счет использования всяких макросов и DSL-ей, чем в других языках. Плюс как ты правильно заметил

> Зато сколько-нибудь сложная логическая конструкция выражается намного естественнее, чем при помощи кратких, но узкозаточенных конструкций других наречий.

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

> Для большинства случяев достаточно и такого, и в любом случяе имплементить примитивный ли полноценный пролог на лиспе всё-таки луче. И присоединить внешний, готовый, к лиспопроге прикрутить нисколько не сложнее чем к с++шной.

Ага. Для этого придется написать немножечка биндингов. Для Си они уже написаны.

> Что не так с CLOS?

Таки сложная зараза. Я мультиметоды до сих пор так и не освоил. И потом, как я пока понимаю, CLOS -- таки не настоящий ООП, ибо инкапсуляция в нем таки ненастоящая. Хотя уникальность такого подхода слегка интригует.

> платой за относительно простой синтаксис, является необходимость держать в голове кучу различных функций, макросов и специальных форм.

Специально для таких случаев предназначены APROPOS, DESCRIBE, а также SLIME :-).

А вообще, если сравнить с количеством man 2 (кажется) для C, то всерьез задумаешься над тем, платой за что в этом языке является необходимость "держать в голове кучу различных функций, макросов и специальных форм"? Я уж не вспоминаю за C++, ибо, насколько я понимаю, одна лишь только stl требует держать в голове больше понятий, чем весь CL вместе взятый ;-).

> Все то, что в других языках обозначалось краткой синтаксической конструкцией здесь имеет склонность превращаться в нечто вроде

> (aaaa-bbbb-cccc (xxx-yyyy-zzzz ((a b) (c d))))

Видимо, товарищи слегка опоздали к обсуждению в нашей суперветке о Лиспе :-). Впрочем, не совсем, ибо никак не соберусь опубликовать финальную статистику. Но факт, что после более-менее формального замера оказалось, что Лисп-программы, по крайней мере не длиннее (ну почти той же длины плюс-минус статпогрешность), что и питоновские с окамловскими, и раза в 3 короче программ на С++. А на отдельных задачах (например, построение трансляторов и спецязыков для управления) Лисп может сделать другие языки на порядок.

И это при том, что со стороны всех участников были субъективные претензии к методике. Причем, если лисперы выдвигали примерно те же претензии, что и Вы (одна и та же синтаксическая конструкция в Лиспе и в самом деле длиннее), то со стороны питонистов особенно интересно было услышать, что Лисп "нечестно играет", ибо в нем нет лишних квалификаторных точек и операторов return :-).

> Что проще запомнить: несколько специальных символов или названия функций? Первое по мне так первое гораздо проще. Хотя бы просто исходя из количества символов которые нужно запомнить.

Угу. В свое время меня Perl как раз и отпугнул тем количеством спецсимволов, которое в нем нужно запомнить. Я так и ниасилил весь этот ужос, и решил перейти к изучению более человеческих языков :-).

> Базовых концепций, из которых выводится всё остальное, намного меньше.

Чем funcall отличается от apply, в каких случаях какой полагается использовать и почему нельзя обойтись одной из этих функций на все случаи жизни?

Аналогичные вопросы относительно setf/setq, defun/defmacro/setq и так далее...

> Запомнить базовых концепций в лиспе нужно столько же сколько и в любом другом языке программирования. А чтобы нормально программировать надо запомнить их даже больше.

Хм? В лиспе базовых концепций всево-то полтора - символы, списки да связывание значений. В с++ в базовые сразу попадают и классы, и функции (которые в лиспе выводятся из списков), и механизьмы управления оперативой, весьма разнообразные, и различия типоф на примитивные/неочень, и многое-многое другое.

> Синтаксис тут особой роли не играет.

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

> операция присваивания

в лиспе нету операций присваивания

> выглядят примерно одинаково не способствует лучшей читабельности лисп-программ.

Это только с непривычки, если глоза не привыкли к обилию скопок и взгляд цепляется за них. А преимущества от применения скопок отнюдь не мнимые и не дело привычки.

>> Для большинства случяев достаточно и такого, и в любом случяе имплементить примитивный ли полноценный пролог на лиспе всё-таки луче. И присоединить внешний, готовый, к лиспопроге прикрутить нисколько не сложнее чем к с++шной.

> Ага. Для этого придется написать немножечка биндингов. Для Си они уже написаны.

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

>> Что не так с CLOS?

> Таки сложная зараза.

Не сложнее с++ наверное, в том тоже много всяких тузегоф позарыто...

> Чем funcall отличается от apply,

скармливанием аргументов вызываемой функции

> в каких случаях какой полагается использовать

когда удобнее

> и почему нельзя обойтись одной из этих функций на все случаи жизни?

можно http://www.lisp.org/HyperSpec/Body/fun_funcall.html#funcall

Notes:
(funcall function arg1 arg2 ...)
== (apply function arg1 arg2 ... nil)
== (apply function (list arg1 arg2 ...))

т.е. сделана одна, как базовая, и вторая на её основе, для удобства, как более пригодная в определённых случяях.

> Аналогичные вопросы относительно setf/setq, defun/defmacro/setq и так далее...

Ответы будут также аналогичны.

> пригодная в определённых случяях.

В каких именно случаях? И какая из них двоих считается "базовой"?

> В лиспе базовых концепций всево-то полтора - символы, списки да связывание значений.

Как всегда, матерые лисперы бревен в своем глазу не замечают :-).

Добавьте к базовым концепциям лямбду и макросы, уже пять получается. А ведь есть еще REPL (который я еще в полном объеме не освоил), блоки и прочие прелести в виде LOOP :-).

>> пригодная в определённых случяях.

> В каких именно случаях?

ну, в разных

> И какая из них двоих считается "базовой"?

да любую ИМХО можно. Тычё, моё пост нечитал? Тамо funcall из apply выводицо, причём двоими способами.

> Добавьте к базовым концепциям лямбду

а чё лямбда? такая же функция, токо без имяни.

> и макросы, уже пять получается.

макросы в с++ тож еся. Причём извращённые. И шаблоны еся. И overloaded функцеи/операторы, особенно последние. А в лиспе - макрос и макрос, всё это заменяет и в любом чястном случяе проще, короче и адекватнее с++ного костыля.

> А ведь есть еще REPL (который я еще в полном объеме не освоил),

Чё тамо осваивать? REPL он и есь REPL

> блоки и прочие прелести в виде LOOP :-).

К базовым это никак не отнесёш. А в с++ блоки и прочие прелести в виде for, while, do while, goto итп - базовые и остальными средствами наречия нереализуюцо.

> Тычё, моё пост нечитал?

Читал. Интересует вопрос, какая из них более кошерная.

Кстати, это к вопросу об избыточности CL.

> а чё лямбда? такая же функция, токо без имяни.

Ну, тогда заменим в базовых понятиях лямбду на функции, один хрен. Просто для меня слегка наоборот: функция -- это такая же переменная, только с лямбда-значением. Это по всякому ближе к "переменным и связываниям значений". А defun при этом сводится к setq.

> А в лиспе - макрос и макрос, всё это заменяет и в любом чястном случяе проще, короче и адекватнее с++ного костыля.

Тем не менее, фундаментальное понятие есть. Не нужно было прибедняться.

> Чё тамо осваивать?

А осваивать то блин, что иногда совершенно сказочные глюки отлавливаются. Например, когда простое добавление параметра в макроид может приводить к серьезным ошибкам при load, в то время, как из среды сей код чудно исполняется. Или когда при load возникают ошибки несвязанной переменной, когда ты только что ее связывал. Или когда после первого вызова функция ведет себя неправильно, а после второго -- уже правильно. Или совершенно непостижимые ошибки, когда подстановка сама по себе не работает, а с #. -- на ура, или наоборот. Ибо eval-when я тоже отношу к прелестям REPL.

> К базовым это никак не отнесёш.

Грубо говоря, с трудом представляю, как BLOCK и GO выражаются через базовые понятия.

>> Тычё, моё пост нечитал?

> Читал. Интересует вопрос, какая из них более кошерная.

> Кстати, это к вопросу об избыточности CL.

А как кошерно обращяться к элементу структуры в с++? Ведь есть и . и ->, взаимозаменяемые? И можно либо только

astruct.x (*astructptr).x и даже ([0]astructptr).x astructptr[0].x

либо только

astructptr->x (&astruct)->x

это ужо к вопросу об избиточности с++, где непонятки начинаюцо уже с самых основ, доступа к структурам данных.

> Просто для меня слегка наоборот: функция -- это такая же переменная, только с лямбда-значением. Это по всякому ближе к "переменным и связываниям значений". А defun при этом сводится к setq.

ну можно и так. В с++ переменная содержит значение или значение хранится внутре переменной?

>> А в лиспе - макрос и макрос, всё это заменяет и в любом чястном случяе проще, короче и адекватнее с++ного костыля.

> Тем не менее, фундаментальное понятие есть. Не нужно было прибедняться.

Есть, но я умышленно упомянал понятия, которые есть только в одном из рассматриваемых наречий.

> иногда совершенно сказочные глюки отлавливаются.

ужснахъ

>> К базовым это никак не отнесёш.

> Грубо говоря, с трудом представляю, как BLOCK и GO выражаются через базовые понятия.

http://home.pipeline.com/~hbaker1/MetaCircular.html

We will show that only one of the three non-local exit mechanisms block/return-from, tagbody/go, catch/throw is required to be primitive, by showing how to emulate any two in terms of the third.

> А как кошерно обращяться к элементу структуры в с++?

Предлагаю оставить в покое проблемы линчевания негров в c++. Речь идет о том, что мне на днях потребовалось построить несколько замыканий и макросов к их вызовам. Так вот, для генераторов везде предлагают использовать funcall, что я и делал. А потом возникла мысль, почему никто не вызывает замыкание через apply? И вообще, возможны ли конструкции вида (apply f), то есть, без аргументов?

> only one of the three

Но тем не менее, хотя бы одна из них должна быть. Для аскетов, это, конечно же, tagbody/go, для нормальных программистов -- block/return. Ну а catch/throw -- это уж точно для красоты.

Хотя в Lua, например, обработка исключения является таким же обычным способом передачи управления, как и ветвление. Можно даже придумать язык, в котором единственным способом передачи управления является генерация исключительной ситуации...

> Предлагаю оставить в покое проблемы линчевания негров в c++.

Почему? Это ведь забавно.

> Так вот, для генераторов везде предлагают использовать funcall, что я и делал. А потом возникла мысль, почему никто не вызывает замыкание через apply?

http://www.lisp.org/HyperSpec/Body/fun_apply.html#apply

Syntax:

apply function &rest args+ => result*

args---a spreadable argument list designator.

http://www.lisp.org/HyperSpec/Body/glo_s.html#spreadable_argument_list_design...

http://www.lisp.org/HyperSpec/Body/fun_funcall.html#funcall

funcall function &rest args => result*

args---arguments to the function.

http://www.lisp.org/HyperSpec/Body/glo_a.html#argument

Вроде всё доступно расписано. В funcall скармливаются сами аргументы, а в apply - их список.

> И вообще, возможны ли конструкции вида (apply f), то есть, без аргументов?

Согласно определению apply - изя. Если не хош чёбы функция, вызватая чз apply получила какие-либо аргументы, придёцо скормить apply пустой список.

> Но тем не менее, хотя бы одна из них должна быть.

Ещё бы! Ты ведь не хотиш построенное на пустом месте, вообще без аксиоматики?

> Можно даже придумать язык, в котором единственным способом передачи управления является генерация исключительной ситуации...

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

> Во-вторых в этом и заключается профессионализм.

Профессионализм заключается в качестве софта, а не в знаниях каких-то запредельных тонкостей языка. Зачем языку быть настолько тонким? Это ведь рабочий инструмент, не игрушка.

> Да. Именно за это его и любят ;)

Совершенно верно. Те самые профессионалы и любят его за то, что всегда есть где порыться и разобраться -- а потом хвастаться друг другу своим профессионализмом, создавая всяческие совершенно нечитаемые конструкции. А работа-то где?

>Конечно, её можно написать на Haskell. А GUI к ней вы тоже будете писать на Haskell ? Это ведь тоже специализированный язык...

Да, гуи тоже буду писать. Хаскель -- язык общего назначения, универсальный то есть. И с++ никогда не будет рядом стоять с ним по гибкости и быстроте решения задач :-)

Немного конкретнее:

>В данном случае такое разбирательство ведёт к пониманию механизмов работы с памятью, что отнюдь не лишнее - в любом языке эти механизмы есть, просто в некоторых они скрыты.

Немного гугления:

> http://www.thescripts.com/forum/thread59994.html I would probably use std::auto_ptr. I don't use that style of programming myself and so have little use for std::auto_ptr. I find the semantics of this class so treacherous, particularly the part where the assignment operation changes the objects on both sides (!), that I greatly prefer boost::shared_ptr for general use.

К сожалению, сам плохо разбираюсь в с++, но вполне доверяю этим словам.

И как, уверены, что механизмы работы с памятью их отличают? :-)

> Вроде всё доступно расписано. В funcall скармливаются сами аргументы, а в apply - их список.

Вот за что убивает стандарт, так это либо за полное отсутствие примеров, либо за их невообразимую извращенность :-(.

> Согласно определению apply - изя.

Тогда становится ясным ареал обитания funcall -- вызов замыканий без аргументов.

Думаю, дискуссия исчерпана.

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

Мня, так я и в самом деле не подумал. Например, вообразить, как d C/C++ реализовать continue, break и return через goto -- задачка не для слабонервных :-). Или while через if, хотя if через while -- еще возможно. Но все-равно тяжело, даже с макросами :-).

> Вот за что убивает стандарт, так это либо за полное отсутствие примеров, либо за их невообразимую извращенность :-(.

Странно, а мне кажецо там всё неплохо расписато и примеры есь даже для самых примитивных случеев.

> Тогда становится ясным ареал обитания funcall -- вызов замыканий без аргументов.

Хм, не совсем так. (funcall #'beda) - это тоже самое что (apply #'beda nil). Если параметры ужо в списке - удобнее (apply #'beda params), а если россыпью - удобнее (funcall #'beda a b c) хотя (apply #'beda (list a b c)) даст тот же результат.

> Думаю, дискуссия исчерпана.

Жалко, даже непофлеймили :(

> Хм? В лиспе базовых концепций всево-то полтора - символы, списки да связывание значений. В с++ в базовые сразу попадают и классы, и функции (которые в лиспе выводятся из списков), и механизьмы управления оперативой, весьма разнообразные, и различия типоф на примитивные/неочень, и многое-многое другое.

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

В лиспе стройные концепции присутствуют только на уровне синтаксиса, и то ценой запоминания всяких функций.

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

Так тут как раз семантика основную роль играет. Синтаксис играет роль второстепенную. А семантика у лиспа далеко не тривиальная. Не проще чем у других языков

> в лиспе нету операций присваивания

Тю, а что же такое set, setq, setf и иже с ними ? Специальные формы, да ?

>Это только с непривычки, если глоза не привыкли к обилию скопок и взгляд цепляется за них. А преимущества от применения скопок отнюдь не мнимые и не дело привычки.

Мешанина она и есть мешанина со временем начинаешь в ней разбираться чуточку лучше, это понятно.

> На сях есь биндинги к прологу, написатому на лиспе? Ну может быть и лисповые биндинги к прологу, написатому на сях ужо гдето есть готовые?

А разве есть сколько нибудь вменяемые прологи на лиспе ? Велосипеды конечно в расчет не берем :)

> Видимо, товарищи слегка опоздали к обсуждению в нашей суперветке о Лиспе :-). Впрочем, не совсем, ибо никак не соберусь опубликовать финальную статистику. Но факт, что после более-менее формального замера оказалось, что Лисп-программы, по крайней мере не длиннее (ну почти той же длины плюс-минус статпогрешность), что и питоновские с окамловскими, и раза в 3 короче программ на С++. А на отдельных задачах (например, построение трансляторов и спецязыков для управления) Лисп может сделать другие языки на порядок.

Таки сравнивать С++ и лисп немного не корректно, не находите ?

> В любом достаточно развитом лиспе помимо списков и символов должны существовать массивы, хеш-таблицы, макросы, функции и прочая хрень. Из списков и символов это не выводится. Это требует отдельного обоснования. Семантически это отдельные языковые конструкции.

Чётак? Функции, и прочяя хрень легко представимы ввиде списков.

> В лиспе стройные концепции присутствуют только на уровне синтаксиса, и то ценой запоминания всяких функций.

В других извесных мне наречиях и этого нету.

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

> Так тут как раз семантика основную роль играет. Синтаксис играет роль второстепенную. А семантика у лиспа далеко не тривиальная. Не проще чем у других языков

Типо семантика не описывает поведения синтаксических конструкций и ваще с синтаксисом не связата?

>> в лиспе нету операций присваивания

> Тю, а что же такое set, setq, setf и иже с ними ? Специальные формы, да ?

Странно, что бы это могло быть? Специальные формы и макросы, кои связывают символ со значением?

> Мешанина она и есть мешанина со временем начинаешь в ней разбираться чуточку лучше, это понятно.

Это точно, со временем в с++шной мешанине можно насобачиться разбираться. Только зачем итти на такие жертвы, не очень пока понятно.

>> На сях есь биндинги к прологу, написатому на лиспе? Ну может быть и лисповые биндинги к прологу, написатому на сях ужо гдето есть готовые?

> А разве есть сколько нибудь вменяемые прологи на лиспе ? Велосипеды конечно в расчет не берем :)

беспонятия, никогда не выяснял