о развитии ЯП

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

Почему нет? А с чем нужно? С висуалвасиком?

> http://www.jetbrains.com/mps/index.html > Это разве не то, что vsl хотел сделать?

HelloWorld посмотрел - поплохело... :)

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

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

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

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

Естественно - примитвно простой синтаксис, который суть символьная запись АСД, является отличительной чертой лиспа. В некоторых случаях положительной в некоторых - отрицательной.

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

Связана конечно. Синтаксис это форма представления программы. Семантика это ее содержательный смысл. При написании программы основную роль ИМХО играет ее смысл, а не синтаксическая стройность. Поэтому я и признаю стройность лиспа ТОЛЬКО на уровне синтаксиса. С точки зрения семаники конструкции (setq a 1) и (defun fact (x) ...) принципиально различны. Более того большое число семантических примитвов в лиспе не позволяет мне назвать этот язык очень простым.

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

>Странно, что бы это могло быть? Специальные формы и макросы, кои связывают символ со значением? Это тонкости. Семантически set* - операция присваивания (изменения состояния программного окружения). А так - назови ее хоть как, смысл от этого не меняется.

> Почему нет? А с чем нужно? С висуалвасиком?

Наиболее корректно сравнение ИМХО с питоном и руби. Если отбросить типизацию, то с окамелом и немерле. Вообще сравнение языков программирования занятие наблагодарное :) Однозначных критериев пока не выработано.

а... ну еще со смолтолком

c tcl-ем можно

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

Дыкть, суть методики как раз в том, что можно сравнивать что угодно с чем угодно. Даже Brainf**k с Прологом, если понадобиться. Возможно, не всегда точно, так ведь индекс Доу-Джонса то же ведь не истина в последней инстанции. Ведь сравнивать IT-индустрию с тяжелым машиностроением и розничной торговлей немного некорректно. Однако ж, сравнивают как-то?

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

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

> Дыкть, суть методики как раз в том, что можно сравнивать что угодно с чем угодно. Даже Brainf**k с Прологом, если понадобиться. Возможно, не всегда точно, так ведь индекс Доу-Джонса то же ведь не истина в последней инстанции. Ведь сравнивать IT-индустрию с тяжелым машиностроением и розничной торговлей немного некорректно. Однако ж, сравнивают как-то?

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

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

Дыкть, по ходу и придумали. И даже порадоваться успели. Если б не хозяйственная текучка, уже бы и contest закрыли бы. Ну ничего, в субботу попробую добраться.

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

Синтаксис и семантика - это две стороны _одной_ медали, оне неразрывно связаты. Смотри простой пример: мне нужно натти например длину n-мерново вектора. На лиспе я делаю чё? Я грю: (sqrt (reduce (lambda (x y) (+ x (* y y))) '(1 2 3) :initial-value 0)), мне нужен корень от операции blah blah blah применённой к списку. Чё я делаю в сях? Цыкл for (опускаем подробности чё цыклу зачемто нужно явно укозать дину вектора), временную переменную, и пшло поехало. s=0; for (i=0; i<n; i++) s += x[i]; s = sqrt(s); Видиш, синтаксис непозволяет мапить множества, и я применяю _другой_ подход. Смысловая нагрузка элементов, т.е. семантика, _мяняяцо_ в зависимости от синтаксиса, неспособново нести некоторую смысловую нагрузку. Чё я делаю на с++? Из шаблона Vector<double> нарождаю класс, присобачиваю ему метод, все дела... Опять таки, в лиспе смысл математический - применение некоего оператора, в сях - алгоритмический, последовательное описание элементарных действий, в с++ - вообще страшно даже подумать чё...

> Естественно - примитвно простой синтаксис, который суть символьная запись АСД, является отличительной чертой лиспа. В некоторых случаях положительной в некоторых - отрицательной.

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

> При написании программы основную роль ИМХО играет ее смысл, а не синтаксическая стройность. Поэтому я и признаю стройность лиспа ТОЛЬКО на уровне синтаксиса. С точки зрения семаники конструкции (setq a 1) и (defun fact (x) ...) принципиально различны. Более того большое число семантических примитвов в лиспе не позволяет мне назвать этот язык очень простым.

а (setq a (lambda (x) (...))) кажется тебе семантически ближе к первой или второй конструкции?

>> Почему нет? А с чем нужно? С висуалвасиком?

> Наиболее корректно сравнение ИМХО с

В принципе, такое сравнение допустимо, ибо и то и другое - наречие программирования. Незнаю руби, но питон ИМХО ближе к уайтспейсу и с++ чем к лиспу.

> Вообще сравнение языков программирования занятие наблагодарное :) Однозначных критериев пока не выработано.

Поэтому и благодарное ИМХО что это один из способов выработать таковые критерии, которые ИМХО нужно.

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

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

Наверное есть, не спорю. Я просто крайне редко до примеров доходил. Всё куда-то торопимся, спешим...

> Синтаксис и семантика - это две стороны _одной_ медали, оне неразрывно связаты.

То что они связаны - не спорю. Вопрос что из них главнее и важнее для программиста :)

> Смотри простой пример: мне нужно натти например длину n-мерново вектора. На лиспе я делаю чё? Я грю: (sqrt (reduce (lambda (x y) (+ x (* y y))) '(1 2 3) :initial-value 0)), мне нужен корень от операции blah blah blah применённой к списку. Чё я делаю в сях? Цыкл for (опускаем подробности чё цыклу зачемто нужно явно укозать дину вектора), временную переменную, и пшло поехало. s=0; for (i=0; i<n; i++) s += x[i]; s = sqrt(s); Видиш, синтаксис непозволяет мапить множества, и я применяю _другой_ подход. Смысловая нагрузка элементов, т.е. семантика, _мяняяцо_ в зависимости от синтаксиса, неспособново нести некоторую смысловую нагрузку. Чё я делаю на с++? Из шаблона Vector<double> нарождаю класс, присобачиваю ему метод, все дела... Опять таки, в лиспе смысл математический - применение некоего оператора, в сях - алгоритмический, последовательное описание элементарных действий, в с++ - вообще страшно даже подумать чё...

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

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

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

Синтаксис есть у любой системы обозначений :) Даже у римских и арабских чисел. Чувак наверное хотел сказать, что у лиспа нет четко выраженного синтаксического анализатора. Тут наверное соглашусь.

> а (setq a (lambda (x) (...))) кажется тебе семантически ближе к первой или второй конструкции?

Мне кажется семантически ближе ко второй. Ибо тип объявляемого объекта в обоих случаях - функция от одного аргумента.

> И в этом случае по понятийной сложности он будет примерно эквивалентен программе на Си++.

Осталось только записать ту же программу в функциональном стиле на С++ и сравнить понятийную сложность. Ваши оценки?

> Наверное есть, не спорю. Я просто крайне редко до примеров доходил. Всё куда-то торопимся, спешим...

С Лиспом спешить нельзя, бо можно нечаянно пропустить саму суть.

А примеры для меня интереснее, как для практика. Ибо в доку лезу не для обучения, а чтобы решить конкретно возникающую проблему. Есть, конечно, вариант, при возникновении проблем постить на ЛОР "Лисп суксь ибо в нем...", но я понимаю, что так долго продолжаться не может :-).

> Я грю: (sqrt (reduce (lambda (x y) (+ x (* y y))) '(1 2 3) :initial-value 0))

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

И если уж в Лиспе доперли сделать две почти идентичные функции для вызова, то почему никто не догадался впихнуть в стандарт функцию возведения в квадрат?

По-моему, это более понятно:

(sqrt (reduce #'+ (mapcar #'sqr '(1 2 3)) :initial-value 0))

> Осталось только записать ту же программу в функциональном стиле на С++ и сравнить понятийную сложность. Ваши оценки?

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

> И если уж в Лиспе доперли сделать две почти идентичные функции для вызова, то почему никто не догадался впихнуть в стандарт функцию возведения в квадрат?

#'expt достаточно :)

> То что они связаны - не спорю. Вопрос что из них главнее и важнее для программиста :)

Как чтото из них может быть важнее если они всегда совместно?

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

Синтаксис позвояет (или не позволяет) составить разные в семантическом плане конструкции. В одном случае я использую примитивный синтаксис и получаю более точное соответствие задаче => самое простое из возможных ибо сложность обусловлена фактически только задачей, в другом - готовую сложную конструкцию, не волне подходящую, потому что наречие не позволяет мне составить другую. Поэтому пришлось в явном виде применять индексы, присвоения, и прочее. И если в одном случае всё просто и надёжно, во втором - _типичная_ ашыпка например забыть первоначальное s=0. Потому что для исходной задачи эта сущность - привнесённая, и легко упускается из виду. Это подобно строительству либо из кирпичей, либо из готовых блоков. Кирпич примитивен, но одинаково пригоден и для строительства пёсьей конуры и для строительства дворца, а блок - только для того, для чего предназначен. Кирпич можно перетаскать и выкласть вручную, а блок - только подёмным краном. Выкладывая кирпичи, я смотрю только на форму задачи, а блоки - приходится ещё смотреть, как они соответствуют моей задаче. То, что здесь было применено функциональное, не суть, а случайность, на лиспе приемлемо выразить любую мыслимую парадигму. Обекты например в лиспе выражены средствами самого лиспа, а для полноценного добавления в с пришлось создавать новое наречие.

> Мне кажется

Вот видиш, ты ужо сомневаешя. На самом деле, семантически (setq ) и (defun ) одинаковы, только действуют на разные пространства, в которых сидят имена аргументов. Почему разные? См. спор лисп1 vs лисп2. Есть аргументы как за, так и против того что пространства разные.

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

Я обычно вызываю clisp в особо тугих случаях и там пытаюсь добиться, чтобы нужная конструкция заработала.

> Ясный перец, понятийная сложность функциональной программы на Си++ будет многократно выше.

Вот и я про то же...

Как чтото из них может быть важнее если они всегда совместно?

Моя шапка связана с моей головой. Когда меня спросят "что важнее - шапка или голова ?", то я отвечу "голова". Так и здесь: вопрос в том, что первично, а что вторично. Я утверждаю что первична семантика и программист в большинстве случаев работает с семантическим уровнем абстракции.

> Синтаксис позвояет (или не позволяет) составить разные в семантическом плане конструкции.

Что-то мы уходим в дебри. Я блин перестаю понимать о чем толкуем. Если бы в лиспе не было бы поддержки на семантическом уровне функций высшего порядка и прочей функциональной мутотни, то никакой бы скобочный синтаксис тебе бы не помог. Ты бы не смог найти длину вектора первым способом. Конкретно: если бы в лиспе небыло конструкций (lambda (...) (....)), (requce ...), (mapcar ...) (quote ...) и пр. то никакими синтаксическими изысканиями ты бы проблему не решил. lambda например - типичный примитив семантического уровня, взятый из теоретических основ функционального программирования. При программированнии человек (ну я по крайней мере) думаю о том, как будет выполняется программа и как в соответствии с этим должна раскладываться на семантические примитивы. Аналогично при чтении программы я стараюсь понять какой смысл кроится за данными синтаксическими конструкциями.

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

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

К слову, просмотрев ряд проектов на CL пришел к выводу, что основная фишка лиспа - макросы, используются сравнительно редко(имеются в виду пользовательские, нестандартные макросы). И тем более редко используются для описания каких-то действительно сложных констукций. Как правило ограничиваются примерно теми же что и сишные макросы: хитрые объявления переменных, функций, генерация несложных параметризованных фрагментов кода. Из сложного часто встречаются определение конструкций навроде сопоставления по шаблону для обработки списков. Больше ничего особенного не заметил. Неужто идея DSL на практике не очень востребована ?

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

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

> Моя шапка связана с моей головой. Когда меня спросят "что важнее - шапка или голова ?", то я отвечу "голова"

шапко и без бошки отлично выживет. А вот понятия (семантику) без символов (синтаксиса) не выразиш, вообще никак.

> Я утверждаю что первична семантика и программист в большинстве случаев работает с семантическим уровнем абстракции.

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

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

Возможно, но причём тут скобочный синтаксис? Скобки используецо только для удобства, при желании можно обойтись и без них, если мешают.

> Конкретно: если бы в лиспе небыло конструкций

А если бы у бабушки был йух...

> Лисп - язык который сочетает в себе различные семантические примитивы:

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

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

Дык, разруха опять-таки, в бошках она... В лиспе намного меньше вещей, которые кроме как тупо вызубрить, никак не узнаеш. Посему, и помнить/разбираться там особо не в чем.

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

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

> Неужто идея DSL на практике не очень востребована ?

ИМХО программеры просто привыкли работать с другими категориями. Вручи например сишнику лисп, и он 99% станет делать например при вычислении длины вектора (setq s 0) (loop blah blah blah) (setq s (sqrt s)) (format t "lisp atstoy!")... Вот и там примерно также, только чюток попродвинутей.

>шапко и без бошки отлично выживет. А вот понятия (семантику) без символов (синтаксиса) не выразиш, вообще никак.

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

> Семантика - она вообще понятийная, т.е. жывёт более в бошке разработчика а не в языке...

Не более и не менее чем синтаксис. У семантики имеются вполне конкретные математические модели (аксиоматические и денотационные и тп). Понятие семантики формализовано. В конкретные конструкции заложен конкретный смысл. И в лиспе каждое смысловое понятие такая же догма как и в си++. Ну например оператор (специальная форма) присваивания вводится как догма. Лямбда вводится как догма. Макросы вводятся как догма. Списки вводятся как догма. Массивы вводятся как догма. С этим ничего не поделаешь.

> Дык, разруха опять-таки, в бошках она... В лиспе намного меньше вещей, которые кроме как тупо вызубрить, никак не узнаеш. Посему, и помнить/разбираться там особо не в чем.

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

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

Относительно "близости к человечьей постановке задачи" - засчет чего ? Все те же конструкции - функции, списки, массивы. Такое сейчас даже в питоне есть. Единственное - макро, но их редко когда можно использовать :)

А лозунг про наречия мне уже оскомину набил. Покажите мне хоть сколько-нибудь сложный пример когда в лисп была встроено и эффективно применялось какое-нибудь новое нетривиальное наречие. Все что я знаю исчерпывается тремя примерами: 1) пролог 2) pattern matching 3) loop Все это настолько рафинированные и ограниченные примерчики что в серьез их воспринимать нельзя.

Что касается большой гибкости синтаксиса лиспа и разрухи в головах могу сказать следующее. В ряде случаев разруха возникает как раз из-за того, что присутствует возможность выбора и чрезмерная гибкость. Помните старичка Дейкстру. Заставил программистов отказаться от goto, а ведь goto - гораздо более мощная конструкция и гибкая чем while, предоставляющая программисту гораздо больше выбора. Зачем казалось бы?

> Помните старичка Дейкстру. Заставил программистов отказаться от goto, а ведь goto - гораздо более мощная конструкция и гибкая чем while, предоставляющая программисту гораздо больше выбора. Зачем казалось бы?

Заставить-то он заставил. Только благодарные программисты в ответ тут же изобрели continue, break и (особенно) return. А также throw-catch. Не забыв, естественно, оформить все это в виде соответствующих синтаксических костылей.

Вот и я хочу спросить программистов: зачем?

> Синтаксические конструкции предназначены только для передачи определенного смысла.

Смысел разный бывает, чтобы ты знал. Где больше смысла, в for (i=0; i<N; i++) {...} или в (map... ...) или в
xor ax, ax
rept:
...
inc ax
cmp ax, cx
jl rept
?

> В конкретные конструкции заложен конкретный смысл. И в лиспе каждое смысловое понятие такая же догма как и в си++. Ну например оператор (специальная форма) присваивания вводится как догма. Лямбда вводится как догма. Макросы вводятся как догма. Списки вводятся как догма. Массивы вводятся как догма. С этим ничего не поделаешь.

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

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

они все логически выводятся из всево нескольких понятий

> Относительно "близости к человечьей постановке задачи" - засчет чего ? Все те же конструкции - функции, списки, массивы. Такое сейчас даже в питоне есть.

За счёт как раз неперегруженного синтаксиса. Ограничений на выражение мысли меньше.

> Единственное - макро, но их редко когда можно использовать :)

Хм? Я чясто использую, жалоб пока не поступало...

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

Обезательно сложный? Ты перечислил достаточно сложные, могу ещё добавить пару, таких как cl-sql. Только ценность сложных сравнительно невелика, сложные нехитро в либу загнать и юзать групповухой. Ценность лиспа как раз в том, что также и сравнительно малые задачи упрошающо десятикратно. Пример такого я приводил в флейме про фразу, где с нуля создаётся конструкция сравнения многих чисел, подобная принятой в математике (типо a < b <= c <d), изначяльно отсосутствуящяя. В пару строк.

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

В лиспе нету свободы выбора. В лиспе есть свобода слова.

> Помните старичка Дейкстру. Заставил программистов отказаться от goto, а ведь goto - гораздо более мощная конструкция и гибкая чем while, предоставляющая программисту гораздо больше выбора. Зачем казалось бы?

Хм. Дык вот и я про то же. goto - ацтой, а синтаксис йазыга не позволяет сделать из нево while. Нафих он while навязал, если с ево помощью теперь нельзя в свою очередь map... соорудить? Проще было синтаксис сменить на нормальный, и полезнее...

> Все те же конструкции - функции, списки, массивы. Такое сейчас даже в питоне есть.

В питоне ещё дофига всево есть, либы километровой длины и на кажный чих функция/обект готовые. Это хшё? Только для быдлокодеринга шаблонных задач. Второй делфи, понимаеш, растёт. "...ищет готовый компонент в сети. Если компонент не найден, грит чё задачя нерешаема в принципе."

>Смысел разный бывает, чтобы ты знал. Где больше смысла, в for (i=0; i<N; i++) {...} или в (map... ...) или в xor ax, ax rept: ... inc ax cmp ax, cx jl rept ?

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

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

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

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

Приведи пример.

>Обезательно сложный? Ты перечислил достаточно сложные, могу ещё добавить пару, таких как cl-sql. Только ценность сложных сравнительно невелика, сложные нехитро в либу загнать и юзать групповухой. Ценность лиспа как раз в том, что также и сравнительно малые задачи упрошающо десятикратно. Пример такого я приводил в флейме про фразу, где с нуля создаётся конструкция сравнения многих чисел, подобная принятой в математике (типо a < b <= c <d), изначяльно отсосутствуящяя. В пару строк.

Кинь мне ссылку, я посмотрю

> В лиспе нету свободы выбора. В лиспе есть свобода слова.

Лозунг. "Исскуство рождается в застенках, а умирает на свободе" :) Исходя из этого треда я знаю как минимум три способа расчета длины вектора на лиспе. Это не свобода выбора ?

> Хм. Дык вот и я про то же. goto - ацтой, а синтаксис йазыга не позволяет сделать из нево while. Нафих он while навязал, если с ево помощью теперь нельзя в свою очередь map... соорудить? Проще было синтаксис сменить на нормальный, и полезнее..

Вообще-то сваять map при помощи while можно без особых проблем :) Кстати в лиспе есть goto ?

> Заставить-то он заставил. Только благодарные программисты в ответ тут же изобрели continue, break и (особенно) return. А также throw-catch. Не забыв, естественно, оформить все это в виде соответствующих синтаксических костылей.

Ну это до гото все равно не дотягивает по функциональным возможностям. Так, мелкий синтаксический сахар. А со throw-catch вообще имхо обрели гораздо больше проблем чем выгоды :)

> Мне что-то начинает это надоедать.

Не поверишь, но после "Фразы о лиспе" ты оригинален ещё мение :)

> Кстати в лиспе есть goto ?

go?

> Не поверишь, но после "Фразы о лиспе" ты оригинален ещё мение :)

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

> Мне что-то начинает это надоедать.

Ну как хош

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

потому что он имеет примерно одинаковый уровень "универсальности". В лиспе ево можно сократить до чястных случяев типо dotimes, doseq, итд. А в остальных такое сокращение делается только с большим ущербом для простоты записи. И именно по вине ограниченности синтаксиса. Поэтому, в других наречиях таковое сокращение либо вводится в виде "догмы", не выражаемой через другие конструкции, либо неиспользуецо вообще.

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

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

> Только без ненужных скобок.

ещё раз, в лиспе скопки не являются необходимыми и используются только для удобства. Всю эту ерунду можно записать без скопков и на лиспе, только тогда могут утратиться некоторые преимущества.

> Приведи пример.

clsql. И вот, ниже

> Кинь мне ссылку, я посмотрю

http://www.linux.org.ru/jump-message.jsp?msgid=1587106#1589825

> Исходя из этого треда я знаю как минимум три способа расчета длины вектора на лиспе. Это не свобода выбора ?

Не. Их может быть ваще +inf. Вот ещё, тоже способ без reduce: (sqrt (apply #'+ (mapcar (lambda (x) (* x x)) '(1 2 3)))). Или (let ((s 0)) (dolist (x '(1 2 3)) (setq s (+ s (* x x)))) (sqrt s)). Или даже (defun vect-len (v &optional (sum 0)) (if v (vect-len (rest v) (+ sum ((lambda (x) (* x x)) (first v)))) (sqrt sum))). Это _не_ свобода выбора, ибо всё это делается на минимуме изначально введённых сущностей, всё остальное делаецо на выведенных из них. Свобода выбора это когда сидиш как дурак и выбираеш между for, while, do while, рекурсией и прочим, понимая чё тебе нужно _выбрать_ наименее плохое, а не создать вполстроки самое оптимальное.

> Вообще-то сваять map при помощи while можно без особых проблем :)

Ок, попробуй своять map в с++, так чёбы им можно было пользоваться легко и непринуждённо, как лисповым.

> Кстати в лиспе есть goto ?

Есть, почему бы ему не есть?

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

Ты забыл добавить - это касалось анализа языков только на одной задаче (ну там ещё сбоку парочка мелких анализов была). Да, на этой задаче разницы "в разы" не вышло.

Но дело даже не в этом. Ты начинаешь повторять всё то, что в том топике было уже переговорено. Поэтому я и высказался про твою "оригинальность".

Ты хочешь начать всё с начала? :)

(loop for x across vec sum (* x x) 
      into sum finally (return (sqrt sum)))