Здравствуйте, VladD2, Вы писали:

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

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

Здравствуйте, Mirrorer, Вы писали:

VD>>car/cdr/
M>Так уж исторически сложилось..

Ага. И не стоит при этом называть язык простым. Многим просто запомнить эти "слова" тяжело.

M>Ну ок. Ну сделали бы они head/tail было бы значительно лучче ?

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

M>Да и caddr кстати короче писать чем head(tail(tail ))

Да, ды, несомнено короче. Ну, куда уж там каким нибудь:

x : y : t

Ладно, защищать "синтаксис" Лиспа занятие неблагодарное. Он не интуитивен, хреново запоминается и очень низкоуровневый. Тут с тобой только лиспоманы согласятся, ну, и любители бессмысленных споров.

M>Префиксная ?

Да.

M>Ну да она специфична.

Она в первю очередь непривычна, а значит мешает обучению.

M>А в случае с XML это не напрягает ?

А XML стал ЯП и его предлагаю как первый язык?

M>Тем более что при программировании нетривиальных макросов придется работать с AST.

Да, да, притягивание за ужи разной муры типа макросов — это главное когда речь идет о первом ЯП для обучения ФП.
Продолжайте судрь в том же духе. Вам ведь совершенно по фиг что и о чем говорить.

M>Тем не менее я считаю что на практике лучше применять что-то другое. Scheme он отлично подходит для обучения ФП.

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

M>А по поводу Хаскеля. Он хорош для обученя ФП в том смысле что он pure

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

M>(ну или что-то типа того ) Человек который его начинает изучать не сможет реализовать программу в императивном стиле.

Ой ли? Берем IO-монаду и захриначиваем мега-императивный код.
И что характерно его можно захреначить на любом ЯП. Ведь императивный стиль не может не поддерживаться языком пригодным для написания программ для современного компьютера.

M> Ему придется плеваться на то что все не так, как он привык, и он на своей шкуре почувствует где ФП дает какой-то плюс, а где удобне было бы попользоваться старым добрым императивом. Обучение ФП на основе Хаскела это что-то типа обучения плаванию путем выбрасывания на середине озера. Злобно но эффективно.

Хороший подход в обучении. Сам научился так плавать (упав с лодки).

M>Альтернативой может быть изучение ФП на основе не pure языков типа OCaml или Nemerle. Но человек с опытом императивного программирования будет поначалу все время думать по императивному. Поэтому путь до просветления и понимания обласит применимости ФП фишек в таком случае будет долше. ИМХО естественно.

Ну, вот мы и дошли до действительно интересного момента.
Я начал работать над проектом Интеграции Немерла с VS 2005 в гордом одиночестве (кстати, твое сообщение украло у меня 15 минут от работы над ней, хорошо, что я пареллельно поел ). Потом ко мне начали подключаться другие программисты. Не все из них много сделали для проекта, но у них у всех была одна интересная особенность! Они все были "императивными программистами" (преимущественно с C++/C#-прошлым).

Так вот, я имел возможность наблюдать, как многие из них постигали ФП на практике. Обычно, мелких подсказок, а то и просто чтение нашей (с Туленцывым) статьи, хватало, чтобы они постепенно изменяли свой подход в кодировании. Сначала это был чисто императивный стиль. Постепенно в нем появлялись те или иные приемы из ФП. И что самое приятное и забавное одновременно большинство из них ссали кипятком, когда открывали для себя те или иные аспекты (т.е. это не было нудным обучением, это были приятные мелкие открытия). Происходило это потому, что ФП давал им не какой-то там идеологический булшит как это принято в мире ФП, а практически сокращал и упрощал их код! Вместо цикла преобразующего список в строку они постепенно перешли к вызову пары функций. Вместо тонны if-ов к использованию сопоставления с образцом. В местах, где ООП давал не лучший результат, стали использовать варианты (алгебраические типы данных) и сопоставление с образцом. Со временем они освоили "другой" полиморфизм (отличный от виртуальных функций и наследования) и другие аспекты ФП.

Остается вопрос, стали ли они при этом функциональными программистами? На мой взгляд — нет. Они стали программистами, освоившими функциональный стиль программирования. Это конечно плохо для тех, кто пытается ваять лагерь непримиримых функциональщиков, готовых забрасывать функциональные озера трупами ни в чем не повинных императивщиков. Но они явно стали более продуктивными.

Так что конечно Nemerle (не могу сказать за OCaml, так как серьезных проектов на нем не вел, но по идее и он тоже) это ужасный язык с точки зрения настоящих функциональщиков. Он можно сказать вероломный.

Здравствуйте, CrazyClown, Вы писали:

VD>>А SICP даже на русском нет.
CC> Говорят, что есть. Я не видел. Мне по фигу. Не считаю нужным учить тех, кто не может читать на английском.
здесь

VD>Без разницы
хз, хз...
Напр. императивную концепцию я бы посоветовал изучать с Паскаля а не с С++

Здравствуйте, <Аноним>, Вы писали:

VD>>Без разницы
А>хз, хз...
А>Напр. императивную концепцию я бы посоветовал изучать с Паскаля а не с С++

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

Здравствуйте, VladD2, Вы писали:

VD>car/cdr/
Так уж исторически сложилось..
Ну ок. Ну сделали бы они head/tail было бы значительно лучче ?
Да и caddr кстати короче писать чем head(tail(tail ))


VD>cons
construst-new-list или что-то вроде конечно понятнее.
Но имхо это как разница между Pow и Power или Exp и Exponent

VD>/посфиксная запись/
VD>AST вместо синтаксиса...

Префиксная ? Ну да она специфична.

А в случае с XML это не напрягает ?
Я же уже неоднократно приводил пример

<add>
  <x>
  <y>
</add>

(add x y)

Есть принципиальная разница в понимании этих кусков кода ?

Тем более что при программировании нетривиальных макросов придется работать с AST.
Для Немерле AST это отдельное измерение. А для Scheme это тот же язык.
Пример с синтаксическим дифференцированием в SICP меня просто поразил своей простотой и красотой. Без префиксной нотации оно было бы больше и не настолько элегантно.

Тем не менее я считаю что на практике лучше применять что-то другое. Scheme он отлично подходит для обучения ФП.

А по поводу Хаскеля. Он хорош для обученя ФП в том смысле что он pure(ну или что-то типа того ) Человек который его начинает изучать не сможет реализовать программу в императивном стиле. Ему придется плеваться на то что все не так, как он привык, и он на своей шкуре почувствует где ФП дает какой-то плюс, а где удобне было бы попользоваться старым добрым императивом. Обучение ФП на основе Хаскела это что-то типа обучения плаванию путем выбрасывания на середине озера. Злобно но эффективно.

Альтернативой может быть изучение ФП на основе не pure языков типа OCaml или Nemerle. Но человек с опытом императивного программирования будет поначалу все время думать по императивному. Поэтому путь до просветления и понимания обласит применимости ФП фишек в таком случае будет долше. ИМХО естественно.

Здравствуйте, VladD2, Вы писали:

VD>А SICP даже на русском нет.

Есть, причём это обсуждалось на этом форуме.
Цифровой вариант можно найти в сети.

Здравствуйте, deniok, Вы писали:

D>Трурль, наверное, спит; сделаю сам

С ремувами и фильтрами неэффективно и не слишком красиво получается. Вот вариант перестановок получше:

perm [] = [[]]
perm (x:xs) = [ps ++ x:qs | rs <- perm xs, (ps,qs) <- splits rs]

-- эквивалент splits xs = inits xs `zip` tails xs
splits [] = [([], [])]
splits xxs@(x:xs) = ([], xxs) : [(x:ps, qs) | (ps,qs) <- splits xs]

Здравствуйте, VladD2, Вы писали:

VD>А SICP даже на русском нет.

http://newstar.rinet.ru/~goga/sicp/sicp.pdf

Здравствуйте, <Аноним>, Вы писали:

А>Хочу начать учить
А>функциональное программирование для общего развития.
А>Не хочется изучать что-то оторванное от реальности.
А>Пока думаю изучать Erlang.

А>Какой язык вы можете посоветовать?

Без разницы. Тут как в сексе. Главное процесс. Изучай Erlang если хочется.

Здравствуйте, lomeo, Вы писали:

L>Во-первых, запись там не посфиксная,

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

L>такой записи вообще не существует.

На этот раз до орфографии докапывашся? Или считашь что постфиксной нотации не существует?

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

L>Во-вторых, я не понял, с чем именно ты не согласен — с тем, что неплохо начинать учить ФП со схемы, или с тем, что схема — простой язык? Или и с тем и с другим?

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

L>А то, что в MIT только те, у кого психика травмирована я в курсе, ага.

Давай теперь прикрываться громкими именами. Правильно сморозил глупость. Тут уже без демагогии и апелляции к авторитетам никак не обойтись. И фиг с ним, что тот же МИТ принял решение использовать для обучения программированию Питон. И что Лисп там используется для курса "Компьютерная наука".

Здравствуйте, VladD2, Вы писали:

VD>Как я уже сказал, по фигу какой язык учить. Тут важнее качество учебника/учителя.

Более качественных учебников, чем SICP, в природе пока не наблюдалось.

VD>Но то что Схема — это простой язык конечно бред.

Обоснвоаний конечно же не будет, так?

L>>А то, что в MIT только те, у кого психика травмирована я в курсе, ага.

VD> И фиг с ним, что тот же МИТ принял решение использовать для обучения программированию Питон.

Ага, для паяльников. Всем остальным — Схема. И, кстати, MIT не один — еще и Беркли, и Стенфорд, и CMU.

Здравствуйте, deniok, Вы писали:

D>Вообще решение в лоб — выкинуть повторяющиеся элементы, написав функцию uniq
D>

D>uniq $ perm "aabc"
D>

D>но оно, очевидно, не самое эффективное.
D>Вечером подумаю.

Вечер — понятие сильно растяжимое. Такой день сегодня хороший. Выложу-ка я свое решение ниже.
Между прочим, задача очень практическая и нижепоследующая функция, только модифицированная для выдачи дерева Data.Tree вместо вложенных списков, крутится в моем решении Rectangle Strip Packing Problem.

-- perm' принимает список после group(By)
perm' [] = [[]]
perm' xs = intern' xs
    where
    intern' = concatMap (uncurry intern) . splits'
    intern [] [[q]] = [[q]]
    intern ps ((q:qs'):qs) = map (q:) $ intern' $ (ps++) $ case qs' of
        [] -> qs
        _ -> qs':qs

-- splits' это splits без последнего элемента
splits' xs@[_] = [([], xs)]
splits' xxs@(x:xs) = ([], xxs) : [(x:ps, qs) | (ps,qs) <- splits' xs]

Здравствуйте, Gaperton, Вы писали:

G>Во-вторых, это, к сожалению, пока единственный ФЯ, на котором не только говорят,

ФЯ на которых говорят . Не знаю, по-моему только Иверсон над этим задумывался в своей классической статье: Notation as a Tool of Thought &mdash; Kenneth E. Iverson.

G> но и делают промышленный софт.

А как же Common Lisp? Он уж пораспространеннее Erlangа будет в коммерческих приложениях.

G> Это единственный неакадемический ФЯ.

Я бы назвал Common Lisp тоже вполне практическим.

Здравствуйте, last shinji, Вы писали:

LS>

LS>(define (mystery x)
LS>  (define (loop x y)
LS>    (if (null? x)
LS>        y
LS>        (let ((temp (cdr x)))
LS>          (set-cdr! x y)
LS>          (loop temp x))))
LS>  (loop x '()))

LS>(define v (list 'a 'b 'c 'd))

LS>(mystery v)
LS>

В каждой итерации берётся голова первого списка и делается головой второго:
(let ((temp (cdr x))) — запоминаем хвост 1 списка
(set-cdr! x y) — голова 1 списка + 2 список
(loop temp x)))) — повторяем итерацию. При первом рекурсивном вызове: temp = (b c d), x = (a), для второго: temp = (c d), x = (b a) и т.д.

CC>Что может быть проще отсутствия синтаксиса (который, соответственно, не надо изучать)?

Его надо изучать. _надо_

Тем более, что не зря пишут люди 7.2 Formal Syntax

А почему изучать?

Потому что надо знать, почему я обязан писать так:

(quote (1 2 3 4 5))

а не так:

(quote 1 2 3 4 5)

и не так:

quote (1 2 3 4 5)

и не так (Haskell ):

quote 1 2 3 4 5

Для того, чтобы понять, например, следующее выражение, надо знать именно синтаксис и как он работает:

(let ((x 2))
  (+ x 3))

Почему не так:

(let (x 2)
  (+ x 3))

и не так:

(let ((x 2)
  (+ x 3))

и не так:

let (x 2)
  (+ x 3)

?

>> Из относительно чистых — можно попробовтаь скачать Turbo Pascal 1.0 —
>> едва ли там много чего добавить успе Кан тoгда
R>В режим турбо паскаля Free Pascal Compiler загнать можно.

Опять же — какого ?
Я же первую версию TP упомянул не из-за любви к программам в 60 КБ весом.
Просто тогда среди всех TP там должно быть наименьшее количество расширений.
Еще можно попробовать найти UCSD PAscal.

А Free Pascal делался с максимальной совметсимостью и "загнать" его можно — вот только обрезать все фичи до TP 1.0 — вряд ли.
И учить программированию, когда перед паскалевским кодом будем десяток строчек обрезающих компилятору разные гланды — совсем не наглядне будет

Здравствуйте, deniok, Вы писали:
D>А в python ленивость — через yield'ы?
Типа того.
Через yield'ы — генераторы, а ленивость — через них, т.к. вычисляется не весь список, а только затребованная часть.

Здравствуйте, <Аноним>, Вы писали:

А>Какой язык вы можете посоветовать?

Посоветую Scheme для начала. Из-за его простоты.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте.
А>Хочу начать учить
А>функциональное программирование для общего развития.
А>Не хочется изучать что-то оторванное от реальности.
А>Пока думаю изучать Erlang.

А>Какой язык вы можете посоветовать?

Erlang — правильный выбор.
Во-первых, самый простой — он проще схемы и прочего, он вообще один из самых простых в мире языков. На полное изучение языка уходит неделя.
Во-вторых, это, к сожалению, пока единственный ФЯ, на котором не только говорят, но и делают промышленный софт. Это единственный неакадемический ФЯ. Он изначально создан для индустриальных применений.

Здравствуйте, VladD2, Вы писали:

L>>Посоветую Scheme для начала. Из-за его простоты.

VD>Логично, блин. car/cdr/cons/посфиксная запись/AST вместо синтаксиса... что может быть проще?

Где там постфиксная запись?!?

Что может быть проще ЕДИНСТВЕННОЙ структуры данных (cons)? Что может быть проще композабельных car/cdr?
Что может быть проще отсутствия синтаксиса (который, соответственно, не надо изучать)?

Вообще, сложность — это понятие объективное. Измеряемое. Вычислимое. Чье либо частное мнение тут вообще не котируется никогда и никак. И как раз объективная сложность у Схемы очень маленькая. Правда, у brainfuck и unlambda она еще меньше, да.

Здравствуйте, VladD2, Вы писали:

VD>Ага. И не стоит при этом называть язык простым. Многим просто запомнить эти "слова" тяжело.

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

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

Синтаксический сахар = сложность. Для той же Схемы полно реализаций сколь угодно навороченного pattern matching, в моем коде на Схеме вообще не найти ни одного car/cdr или их производных. Кое что есть даже в минимальном R5RS (в макрах). Но это уже не есть минимальный, простейший язык. Несовместимы понятия "простой язык" и "синтаксический сахар".

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

Здравствуйте, Mirrorer, Вы писали:

M>Лично я их запомнил через 10 минут игры со списками в интерпретаторе.

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

VD>>

VD>>x : y : t
VD>>

VD>>
M> list comprehensions конечно удобнее для работы со списками чем функции.
M>+1

Это не "list comprehensions". Это просто сахар. А вот как раз list comprehensions на мой взгляд не очень прост для запоминания.

VD>>А на XML стал ЯП и его предлагаю как первый язык?
M>Никак нет, не стал.

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

M>Макросы — мура ? Позволю себе не согласится сударь

Не позволю. Напомню еще раз о сути вопроса. Изучение макросов не входит в понятие "обучение ФП".

M>Синтаксис языка пределно прост.

У Брэйнфака он еще проще. Давай на этом основании признаем Брэйнфак самым прстым языком?

M> Можно даже сказать что он отсутсвует.
M>Достоинство это или недостаток каждый решает для себя.

Речь не о себе. А о обучении. Моря скобок и невнятные названия в примерах (особенно для человека привыкшого к Паскале- и/или С-подобному синтаксису) никак не способствуют упрощению восприятия.

M> Я считаю что для обучения это больше плюс, чем минус. Сущностей которыми приходится оперировать очень мало.

Это заблуждение. Сущностей ровно столько же. Ни if/else, ни вызовы методов никуда не исчезают. Просто из "кодируют" весьма причудливым обрзом. И непривыкшему человеку эту "кодировку" прийдется еще привыкать распозновать.

M> Есть список он же и функция.

Ты когда нибудь пытался объяснить этот факт непосвященному? А сам то сколько "тупил" пока не "въехал" в подобные вещи?

VD>>Ой ли? Берем IO-монаду и захриначиваем мега-императивный код.
M>Как ты думаешь сколько нужно времени человеку чтобы разобраться как работать с монадами ?
M>Пока человек доберется до монад ему придется пользоваться pure functional вещами.

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

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

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

VD>>Я начал работать над проектом Интеграции Немерла с VS 2005 в гордом одиночестве (кстати, твое сообщение украло у меня 15 минут от работы над ней, хорошо, что я пареллельно поел ).
M>[Offtopic]
M>Если бы для интеграции не нужно было качать 100 метровый СДК каждый месяц, то одним разработчиком интеграции стало бы больше
M>[/Offtopic]
Рельно раз в два месяца. Ну, да неужели так плохо с Интернетом в твоих краях?

M>Неужели я со стороны похож на непримиримого функциональщика ?
Я в общем. Меня просто задолбали маньякальные проявления этого сообщества.

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

Это чистейшая отмазка. Ни на изучение, ни на использование этот факт влияния не оказывает. Вон D уже 1.0 и что с того толку? Он находится в куда менее завершенном состоянии.

M> Для тебя это может не быть не имеет большого значения. Но у кого-то могут быть другие мысли на этот счет.

Отмазкой это может быть. Мне тоже когда что-то в лом делать прооще придумать почему это можно не делать.

M>У него очень слабо с документацией. Те же Хаскелл и Scheme имеют кучу документации, статей туториалов, даже видеолекций. В случае с Немерле ситуация выглядит очень печально.

Начнем с того, что как раз на русском информации по Немерлу пожалуй будет по больше чем по Хаскелю или Эрлангу. Я тут лично постарался .
На мой взгляд информции для обучения более чем достаточно. Вводной статьи за глаза хватает чтобы человеку знающему C# начать его использовать. А мастерство один фиг приходит только на практике.

В общем, все кто хотел уже это сделали. Так что тут скорее нужно говорить о недостаточной мотивации.

M>Я бы сам не против написать пару статей про применение N. допустим в сравнении с C# 3.0 Но меня сдерживает отсутсвие нормального описания языка.

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

M> То что оно где-то существует в голове разработчиков или людей которые с ними общаются это здорово конечно. Но хотелось бы увидеть его собранном в одном месте.

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

M>З.Ы. предлагаю тему Haskell/Scheme дальше не развивать.

Дык я просто заметил, что высказывание о том, что Scheme является лучшим ЯП для изучения ФЯ, особенно при условии, что человек просил "практический язык" мягко говоря натянута.

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

Здравствуйте, VladD2, Вы писали:

CC>> Более качественных учебников, чем SICP, в природе пока не наблюдалось.

VD>Почитай на досуге хороший перевод "The C programming language".

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

VD>А SICP даже на русском нет.

Говорят, что есть. Я не видел. Мне по фигу. Не считаю нужным учить тех, кто не может читать на английском.

И, конечно же, "The C Programming Language" как учебник в подметки не годится SICPу. SICP учить программировать, а Керниган&Ричи учат языку Си и Юниксу.

VD>>>Но то что Схема — это простой язык конечно бред.

CC>> Обоснвоаний конечно же не будет, так?

VD>Для тебя нет. У тебя уже извращено восприятие. Фантики не могут оценивать предмет своего фнатизма адекватно.

У меня вообще нет субъективного восприятия. Я признаю только объективные, строгие математические доказательства.

VD>>> И фиг с ним, что тот же МИТ принял решение использовать для обучения программированию Питон.

CC>> Ага, для паяльников.

VD>Что есть "для паяльников"?

Радиоэлектронщики. Совсем не программисты.

УРА! К нам вернулся CopyPaste (он же Kolhoz, он же GNUzaurus).

Здравствуйте, CrazyClown, Вы писали:

CC>Здравствуйте, VladD2, Вы писали:

CC>>> Более качественных учебников, чем SICP, в природе пока не наблюдалось.

VD>>Почитай на досуге хороший перевод "The C programming language".

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

Понты и зазнайсво — это не сюда, плиз. Это рускоязычный форум и люди здесь в первую очередь ищут информацию на русском.

Плю не стоит подменять смысл высказываний. Речь не о русском. Речь о том, что "The C programming language" сделал С мировым лидером на долгие годы. В общем-то если бы ни он, то небыть бы ни С, ни темболее С++, лидерами.

VD>>А SICP даже на русском нет.

CC> И, конечно же, "The C Programming Language" как учебник в подметки не годится SICPу. SICP учить программировать, а Керниган&Ричи учат языку Си и Юниксу.

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

CC> У меня вообще нет субъективного восприятия.

Я плякаль.

CC> Я признаю только объективные, строгие математические доказательства.

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

CC> Радиоэлектронщики. Совсем не программисты.

А зачем программистов учить программировать?

Здравствуйте, Андрей Хропов, Вы писали:

G>> но и делают промышленный софт.

АХ>А как же Common Lisp? Он уж пораспространеннее Erlangа будет в коммерческих приложениях.

Не будет он пораспространеннее Erlang-а в коммерческих приложениях. Даже близко. На Эрланг написано в разы больше коммерческого кода, чем на любом ФЯ, тут даже сравнивать глупо. Простой тест — задайтесь вопросом, какой коммерческий софт обычно ( ) пишут на CLisp, когда думают его коммерчески применить. Для Эрланга несложно ответить на этот вопрос, Lisp же применяется эпизодически где попало. У него даже устоявшейся ниши применений нет. Массово его применяли во времена программы СОИ, в рамках заказов американского министерства обороны. В системах "военного искусственного интеллекта". Даже LISP-процессоры делали. Ушла вместе с Рейганом СОИ — и все. Да и то — коммерческим этот софт можно назвать с большой натяжкой. Он заказной.

Здравствуйте, Mamut, Вы писали:

CC>>Что может быть проще отсутствия синтаксиса (который, соответственно, не надо изучать)?


M>Потому что надо знать, почему я обязан писать так:
M>

M>(quote (1 2 3 4 5))
M>

Тут действует единственное общее правило - первый аргумент списка — это команда, все последующие — ее аргументы.
Поэтому зная, что (quote (1 2 3 4)), ты заодно знаешь, что (fib 20), (+ 1 2), (= 3 4) etc.



M>Для того, чтобы понять, например, следующее выражение, надо знать именно синтаксис и как он работает:
M>

M>(let ((x 2))
M>  (+ x 3))
M>

let — это макрос. Означает он вот что: ((lambda (x)(+ x 3) 2).
Синтаксис тут прежний — команда let принимает аргументы — первый(список-списков): ((x 2)) и второй(выражение): (+ x 3). Синтаксис тут совершенно прежний, а знание того, что let нужно вызывать с двумя аргументами, это не знание синтаксиса, а, скорее, знание API

Все поскипано.

То есть мне все равно надо знать, что списки запихиваются в скобочки, а все это тоже запихивается в скобочки

Здравствуйте, deniok, Вы писали:

D>Здравствуйте, R.K., Вы писали:

D>Класс. Компрехеншен — сила!

Есть такое.

D>A inits и tails — это будут
D>

D>tails [] = [[]]
D>tails xxs@(x:xs) = xxs:[ys | ys <- tails xs]

-- чуть проще, компрехеншн уже не нужен
tails [] = [[]]
tails xxs@(_:xs) = xxs : tails xs

Еще интересная задача сделать перестановки с учетом повторяющихся элементов. Функция perm' должна принимать на вход список списков, полученных от group(By) и возвращать список пермутаций без повторений. Например:

> perm' $ group "aabc"
["aabc","aacb","abac","abca","acab","acba","baac","baca","bcaa","caab","caba","cbaa"]

Здравствуйте, deniok, Вы писали:

D>Вроде понял. intern, приняв, скажем ["a","b"] ["cc","d"], отщепляет первую c и гонит в начало, а остальное собираем в список и снова intern'. Назвать бы их (intern и intern') по-человечески. Вообще, механизм немного похож на мою версию permutations, которая с фильтрами. Там, где у меня была фильтрация, здесь — пересборка списка без q.

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

D>А splits' без последнего элемента — это чтобы в intern' образец ((q:qs'):qs) был неопровержим.

Ну да, чтоб лишнего ветвления в паттернах интерн не было.

Здравствуйте.
Хочу начать учить
функциональное программирование для общего развития.
Не хочется изучать что-то оторванное от реальности.
Пока думаю изучать Erlang.

Какой язык вы можете посоветовать?

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте.
А>Хочу начать учить
А>функциональное программирование для общего развития.
А>Не хочется изучать что-то оторванное от реальности.
А>Пока думаю изучать Erlang.

А>Какой язык вы можете посоветовать?

Так для общего развития или не оторванное от реальности?
Если для развития, то Scheme на основе SICP (это основы) и потом Haskell (после него, можно считать, знаешь все функциональные языки сразу), а если не отрываться от реальности, то лучше вообще забыть про это.

А>Так для общего развития или не оторванное от реальности?
А>Если для развития, то Scheme на основе SICP (это основы) и потом Haskell (после него, можно считать, знаешь все функциональные языки сразу), а если не отрываться от реальности, то лучше вообще забыть про это.

Спасибо за советы.

Объясню свою позицию.
Использовать в коммерческих целях (т.е. на работе
функциональное программирование я пока не собираюсь.
Но изучать язык на котором нельзя написать коммерческий проект как-то не интересно.
Т.е. я считаю что язык не должен быть вещью в себе и для себя.

Здравствуйте, <Аноним>, Вы писали:

А>>Не хочется изучать что-то оторванное от реальности.
...
А>Если для развития, ... то Scheme ... Haskell

(задумчиво) А что... что-то в этом есть...

Здравствуйте, lomeo, Вы писали:

L>Посоветую Scheme для начала. Из-за его простоты.

Логично, блин. car/cdr/cons/посфиксная запись/AST вместо синтаксиса... что может быть проще? Эрланг тут конечно отдыхат.

ЗЫ

Ничего не имею проив Схемы или даже Хаскеля, но мне интересно, это ФП так сильно травмирует восприятие мира, или просто люди с априори травмированным восприятием мира склоны к ФП? Ведь аргументация, ну, просто потрясающая.

Здравствуйте, VladD2, Вы писали:

L>>Посоветую Scheme для начала. Из-за его простоты.

VD>Логично, блин. car/cdr/cons/посфиксная запись/AST вместо синтаксиса... что может быть проще? Эрланг тут конечно отдыхат.

VD>ЗЫ

VD>Ничего не имею проив Схемы или даже Хаскеля, но мне интересно, это ФП так сильно травмирует восприятие мира, или просто люди с априори травмированным восприятием мира склоны к ФП? Ведь аргументация, ну, просто потрясающая.

Во-первых, запись там не посфиксная, такой записи вообще не существует.
Во-вторых, я не понял, с чем именно ты не согласен — с тем, что неплохо начинать учить ФП со схемы, или с тем, что схема — простой язык? Или и с тем и с другим?

А то, что в MIT только те, у кого психика травмирована я в курсе, ага.

Здравствуйте, c-smile, Вы писали:

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

Паскаль еще ладно. Но С++ — это уже перебор.

Да и какой Паскаль? Виртовский? Еги реализацию и найти то уже не просто. А Дельфи будет мало чем отличаться от Явы/C# скажем.

Тогда уж имеет смысл говорить об Обероне . А что? Это более совершенный нежели Паскаль язык. Да и проще он. Вот только не практичный.

В общем, это вы проецируте свой опыт на данный вопрос.

Лично я вообще начинал с С. Но почему-то мне не хочется советовать так же поступать сегодняшним начинающим.

Здравствуйте, VladD2, Вы писали:

VD>>>car/cdr/
VD>Многим просто запомнить эти "слова" тяжело.
Не могу не согласится. Люди они разные.
Лично я их запомнил через 10 минут игры со списками в интерпретаторе.

M>>Да и caddr кстати короче писать чем head(tail(tail ))
VD>Да, ды, несомнено короче. Ну, куда уж там каким нибудь:
VD>

VD>x : y : t
VD>

VD>
list comprehensions конечно удобнее для работы со списками чем функции.
+1

VD>Она в первю очередь непривычна, а значит мешает обучению.
M>>А в случае с XML это не напрягает ?
VD>А на XML стал ЯП и его предлагаю как первый язык?
Никак нет, не стал. Речь исключитлеьно об нотации. Ведь у ХМЛ тоже префиксная нотация. Или лучше скзатаь префиксно-постфиксная. Неужели много людей жалуется что она непонятна?
Ну да ладно. Люди бывают разные и восприятие у них тоже. По этому поводу спорить толку нет.

VD>Да, да, притягивание за ужи разной муры типа макросов — это главное когда речь идет о первом ЯП для обучения ФП.
Макросы — мура ? Позволю себе не согласится сударь
Попробую еще раз объяснить почему именно Scheme.
Синтаксис языка пределно прост. Можно даже сказать что он отсутсвует.
Достоинство это или недостаток каждый решает для себя. Я считаю что для обучения это больше плюс, чем минус. Сущностей которыми приходится оперировать очень мало. Есть список он же и функция. Есть литералы. Но тем не менее на этом простом базисе можно объяснить многие вещи. В том числе и макросы. И есть доступные и понятные статьи, и даже книги по этому делу.
Поэтому ИМХО как язык для обучения Scheme очень хорош. Но применять его на практике скорее всего не придется. О чем я честно и сказал.

VD> В прочем Хаскель действително имеет некоторые приемущества. Так у него офигительные введения. Они мега-круты, так как могут отбить желание иметь дело с ФП почти у любого.
+1

VD>Ой ли? Берем IO-монаду и захриначиваем мега-императивный код.
Как ты думаешь сколько нужно времени человеку чтобы разобраться как работать с монадами ?
Пока человек доберется до монад ему придется пользоваться pure functional вещами. Так что монады это что-то типа спасательного круга до которого в принципе можно доплыть, но для того чтобы до него доплыть уже нужно хоть как-то плавать (продолжая аналогию с лодкой).
И обычно те, кто доплывают до монад не тащат императивные идеи. Но такой способ обучения может завершится летальным исходом.

Хотя для человека задавшего превоначальный вопрос это обсуждение врядли имеет смыл.
Haskell и Scheme ИМХО в промышленности имеют не очень большую область применения.
Имеется ввиду что для большинства задач затраты на реализацию при помощи Haskell\Scheme будут такими же, а то и больше(переход на другие технологии задаром не дается).


VD>Я начал работать над проектом Интеграции Немерла с VS 2005 в гордом одиночестве (кстати, твое сообщение украло у меня 15 минут от работы над ней, хорошо, что я пареллельно поел ).
[Offtopic]
Если бы для интеграции не нужно было качать 100 метровый СДК каждый месяц, то одним разработчиком интеграции стало бы больше
[/Offtopic]

VD> [Кусок нагло вырезан] Со временем они освоили ... и другие аспекты ФП.
Аналогично, шеф (с)
И теперь я плююсь оттого что мне приходится работать на c# 2.0 на .Net CF.
Когда понимаешь что многие вещи можно делать значительно проще и естественнее, то использовать старые подходы настолько противно....


VD>Это конечно плохо для тех кто пытается воять лагеть непримиримых функциональщиков
Неужели я со стороны похож на непримиримого функциональщика ?

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


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

У него очень слабо с документацией. Те же Хаскелл и Scheme имеют кучу документации, статей туториалов, даже видеолекций. В случае с Немерле ситуация выглядит очень печально.
Я бы сам не против написать пару статей про применение N. допустим в сравнении с C# 3.0 Но меня сдерживает отсутсвие нормального описания языка. То что оно где-то существует в голове разработчиков или людей которые с ними общаются это здорово конечно. Но хотелось бы увидеть его собранном в одном месте.

З.Ы. предлагаю тему Haskell/Scheme дальше не развивать.

Здравствуйте, CrazyClown, Вы писали:

CC> Более качественных учебников, чем SICP, в природе пока не наблюдалось.

Почитай на досуге хороший перевод "The C programming language".
А SICP даже на русском нет.

VD>>Но то что Схема — это простой язык конечно бред.

CC> Обоснвоаний конечно же не будет, так?

Для тебя нет. У тебя уже извращено восприятие. Фантики не могут оценивать предмет своего фнатизма адекватно.

VD>> И фиг с ним, что тот же МИТ принял решение использовать для обучения программированию Питон.

CC> Ага, для паяльников.

Что есть "для паяльников"?

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, c-smile, Вы писали:

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

VD>Паскаль еще ладно. Но С++ — это уже перебор.

VD>Да и какой Паскаль? Виртовский? Еги реализацию и найти то уже не просто. А Дельфи будет мало чем отличаться от Явы/C# скажем.

Чистый Паскаль найти легко. Тот же FreePascal например.

VD>Лично я вообще начинал с С. Но почему-то мне не хочется советовать так же поступать сегодняшним начинающим.

Вот пример как надо начинать:

Это студенческая работа: Pascal Compiler (в P-code) + VM + IDE для всего этого дела.

http://www.codeguru.com/cpp/cpp/cpp_mfc/parsing/article.php/c831/

Т.е. имеем и С и Паскаль и MFC.

Здравствуйте, VladD2, Вы писали:

VD>Не позволю. Напомню еще раз о сути вопроса. Изучение макросов не входит в понятие "обучение ФП".
Ну если не входит, тогда Scheme не в кассу. Но без макросистемы и Немерле не особо отличается допустим от F#.

VD>Речь не о себе. А о обучении. Моря скобок и невнятные названия в примерах (особенно для человека привыкшого к Паскале- и/или С-подобному синтаксису) никак не способствуют упрощению восприятия.
Из всех терминов самыми непонятными являются car, cdr. Приведешь еще примеры ?

M>> Есть список он же и функция.
VD>Ты когда нибудь пытался объяснить этот факт непосвященному? А сам то сколько "тупил" пока не "въехал" в подобные вещи?
Мне как-то пришла в голову идея, что Lisp это XML с круглыми скобками. Пришла она мне на день третий или четвертый изучения. Причем все эти дни меня терзало смутное сомнения, что где-то я что-то похожее видел.
Объяснял... Объяснял 3-м знакомым лично. После слов что лисп это ХМЛ было недоумение, потом практически сразу понимание.
Хотя тут дело именно в озарении которое меня посетило. Наверное мне просто повезло.

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

VD>Более того. Человек уже знаком с концепциями ИП и ему ероще будет изучить отличие в подходах, чем осваивать "полностью новый мир".
Опять же с переходом на мою личность. Когда я изучаю что-то я стараюсь забыть все что знал до этого и выстраивать какие-то ассоциации только после того как в мозгу будет построена более менее цельная картина "полностью нового мира". "Premature analogy is the root of all evils" примерно так я думаю. Но опять же это лично мое впечатление. И спорить по этому поводу не вижу смысла.

VD>Рельно раз в два месяца. Ну, да неужели так плохо с Интернетом в твоих краях?
В общем давай по этому вопросу в приват. Может решим что-то.

M>>Он еще не достиг стабильной версии это раз.
VD>Это чистейшая отмазка. Ни на изучение, ни на использование этот факт влияния не оказывает. Вон D уже 1.0 и что с того толку? Он находится в куда менее завершенном состоянии.
Это у меняч чисто психологический момент. Я помню когда игрался с бетой первого дот нета. У меня в один прекрасный момент в неинициализированной строке оказался мусор. После этого я стал маниакально везде ставить

string someString = "";

Прошло это относительно недавно.

VD>Начнем с того, что как раз на русском информации по Немерлу пожалуй будет по больше чем по Хаскелю или Эрлангу.
Объясню что я имею ввиду. Когда я что-то изучаю, то захожу в гугл и ищу статьи по интеерсующей меня информации. Потом начинаю их просматривать. Если мне не нравится как оно написано, я выбираю беру следующий документ. У меня просто может не совпадать стиль мышления с автором. Вот в случае с Немерле особого выбора как раз нету.
Сейчас меня интересует больше всего макросистема, по которой ты обещал написать статью

VD>На мой взгляд информции для обучения более чем достаточно. Вводной статьи за глаза хватает чтобы человеку знающему C# начать его использовать.
VD>В общем, все кто хотел уже это сделали. Так что тут скорее нужно говорить о недостаточной мотивации.
Ага. И еще желательно иметь такую мелочь как компилятор под платформу, на которой человек работает
Это я про Compact Framework.

VD>На самом деле большинство информации о языке доступно на сайте и в статьях. Если что-то не документирвоано, то это уже довольно тонкие аспекты.
Дык дьявол он как раз в деталях...

VD> что Scheme является лучшим ЯП для изучения ФЯ, особенно при условии, что человек просил "практический язык" мягко говоря натянута.
С практичностью я конечно провтыкал. Но честно об этом предупредил.

VD>так как все кто брался за его использование успешно освоили его функциональные фичи.
Тут у меня недостаточно информации чтобы судить.
VD>А вот примеров когда люди брались за изучение ФП на базе Схемы и Хаскеля и бросали это дело так его и неосилив я видел не мало.
А тут +1. Я сам Хаскел изучал в несколько итераций..

VD>вокруг ходили бы толпы Лиспорей и Хаскелистов, а С++-ники и C#-щики прятались бы по углам боясь поднять голову.
Довольно живо представил себе такую картину

Mirrorer wrote:
> Мне как-то пришла в голову идея, что Lisp это XML с круглыми скобками.
> Пришла она мне на день третий или четвертый изучения. Причем все эти дни
> меня терзало смутное сомнения, что где-то я что-то похожее видел.
> Объяснял... Объяснял 3-м знакомым лично. После слов что лисп это ХМЛ
> было недоумение, потом практически сразу понимание.
А что, это непонятно сразу?

Причем, почему-то схемисты и лисповоды — самые ярые противники XML.

Здравствуйте, Cyberax, Вы писали:

>> Объяснял... Объяснял 3-м знакомым лично. После слов что лисп это ХМЛ
>> было недоумение, потом практически сразу понимание.
C>А что, это непонятно сразу?
Неа. Особенно когда везде читаешь что лисп и хаскелевые монады это тебе не ломом пшеницу разгружать...

C>Причем, почему-то схемисты и лисповоды — самые ярые противники XML.

Здравствуйте, Cyberax, Вы писали:

C>Причем, почему-то схемисты и лисповоды — самые ярые противники XML.

Так понятно почему. Из-за синтаксического оверхеда.

(+ a b)

vs.

<plus>
    <a />
    <b />
</plus>

Аноним wrote:
> Так понятно почему. Из-за синтаксического оверхеда.
> (+ a b)
> vs.
> <plus>
> <a />
> <b />
> </plus>
И что? Не вижу проблемы — в современных IDE оба варианта пишутся
примерно с одинаковой скоростью.

Да и не с синтаксисом проблемы, почему-то лисповоды считают, что
S-выражения сразу все проблемы решают.

Здравствуйте, Cyberax, Вы писали:

C>И что? Не вижу проблемы — в современных IDE оба варианта пишутся
C>примерно с одинаковой скоростью.

Нет проблем.
Вы не видите, а я вижу. И никакая IDE мне не помогает одинаково быстро это писать, читать и редактировать.

C>Да и не с синтаксисом проблемы, почему-то лисповоды считают, что
C>S-выражения сразу все проблемы решают.

Я вам рассказываю какие у меня претензии к XML, а не у каких-то абстрактных лисповодов.
Ну и опять же, не знаю как насчет всех проблем, а все те проблемы, что решает XML у меня решают и S-выражения. Только что с большим комфортом.

Здравствуйте, VladD2, Вы писали:

VD>Это чистейшая отмазка. Ни на изучение, ни на использование этот факт влияния не оказывает.

А на обучение на этом языке? (разницу в изучении языка и обучению программированию на языке сам осознаешь?)

VD>Начнем с того, что как раз на русском информации по Немерлу пожалуй будет по больше чем по Хаскелю или Эрлангу.

Про Эрланг и Хаскель — не скажу. А Схему тактично пропустил?

VD>Я тут лично постарался .

Статьи на учебник не сильно тянут, в первую очередь вот почему:

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

НЕ ЗНАЮ Я C#! Мне сначала изучить его? Или подождать SICP на Немерле?

VD>В общем, все кто хотел уже это сделали. Так что тут скорее нужно говорить о недостаточной мотивации.

Если мы говорим ТОЛЬКО о переходе C# -> Nemerle — может быть, в любом другом случае — НЕТ!

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

Немерле — это в первую очередь .NET, а его пока только через C# можно освоить. Итого пока имеем "провал".

VD>Твои аргументы по Немерлу тоже несостоятельны, так как все кто брался за его использование успешно освоили его функциональные фичи.

Обожаю когда говорят за всех и обо всех!

VD>А вот примеров когда люди брались за изучение ФП на базе Схемы и Хаскеля и бросали это дело так его и неосилив я видел не мало.

Естественно, ибо таких на порядки больше!

VD>Если бы это было не так, то вокруг ходили бы толпы Лиспорей и Хаскелистов, а С++-ники и C#-щики прятались бы по углам боясь поднять голову.

Гы-гы, посмотри на форумы по всем CL и схеме — если у Немерле когда-нибудь появится такое-же сообщество — его действительно можно будет считать состоявшимся

И демагогию про С++-ников и C#-щиков разводить не надо — те же сам знаешь, что их ничего не исправит
Или ты думаешь, что их всех исправит Н? Это даже не наивность...

Здравствуйте, CrazyClown, Вы писали:

CC> Что может быть проще ЕДИНСТВЕННОЙ структуры данных (cons)? Что может быть проще композабельных car/cdr?
CC>Что может быть проще отсутствия синтаксиса (который, соответственно, не надо изучать)?

Почему отсутствия? Синтаксис есть, просто он реализуется средствами языка, а не жестко задан спецификацией. Если в Паскале для изучения циклов надо изучить оператор в описании языка, то в Лиспе — несколько стандартных функций/макросов.

Здравствуйте, Овощ, Вы писали:

О>УРА! К нам вернулся CopyPaste (он же Kolhoz, он же GNUzaurus).

Ждем ключевого слова "Дискретная Математика".

Здравствуйте, CrazyClown, Вы писали:

VD>>Как я уже сказал, по фигу какой язык учить. Тут важнее качество учебника/учителя.
CC> Более качественных учебников, чем SICP, в природе пока не наблюдалось.
+1

VD>>Но то что Схема — это простой язык конечно бред.
CC> Обоснвоаний конечно же не будет, так?
Простой и сложный — понятия относительные, а не абсолютные. Схема — достаточно простой язык (Кстати — в изучении? в использовании? или вообще — по мутным критериям вроде "синтаксического оверхэда"(тм)?). Он, допустим, по всем критериям проще, чем CLisp и С++. А Эрланг, в свою очередь, проще Схемы.

G>> Это единственный неакадемический ФЯ.

АХ>Я бы назвал Common Lisp тоже вполне практическим.

У CL есть одна проблемка — неоднозначность реализаций. То есть да, выучить, как писать макросы, например, можно в любой реализации. Но вот ни в threading ни в работу со строками уже не полезешь, потому что они для разных реализаций разные.

Тут правда, все упирается в то, что подразумевается под "выучить ФЯ".

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, <Аноним>, Вы писали:

[skip]
VD>Это хорошо... что ты плоский и зеленый, тфу ты, анонимный и никому неизвестный. Ни то стройные ряды дубокодеров будут шириться до кончины рода человеческого.

Грубо. Не смешно.
-1

Здравствуйте, Андрей Хропов, Вы писали:

АХ>Здравствуйте, Gaperton, Вы писали:

G>>Во-вторых, это, к сожалению, пока единственный ФЯ, на котором не только говорят,

G>> но и делают промышленный софт.

АХ>А как же Common Lisp? Он уж пораспространеннее Erlangа будет в коммерческих приложениях.

Ммм, а можно хоть примерный список? Про Эрланг вот видел, а про CL...

АХ>>А как же Common Lisp? Он уж пораспространеннее Erlangа будет в коммерческих приложениях.

К>Ммм, а можно хоть примерный список? Про Эрланг вот видел, а про CL...


Наверное, имеется в виду вот это: Success Stories

VD>>Да и какой Паскаль? Виртовский? Еги реализацию и найти то уже не просто. А Дельфи будет мало чем отличаться от Явы/C# скажем.
CS>Чистый Паскаль найти легко. Тот же FreePascal например.

Чистый??? ТАм Delphi-расширений до фига, Apple Object Pascal, GNU Pascal...
Вот уж совсем он не чистый.

Из относительно чистых — можно попробовтаь скачать Turbo Pascal 1.0 — едва ли там много чего добавить успе Кан тoгда

Аноним 320 wrote:
> VD>>Да и какой Паскаль? Виртовский? Еги реализацию и найти то уже не
> просто. А Дельфи будет мало чем отличаться от Явы/C# скажем.
> CS>Чистый Паскаль найти легко. Тот же FreePascal например.
>
> Чистый??? ТАм Delphi-расширений до фига, Apple Object Pascal, GNU Pascal...
> Вот уж совсем он не чистый.
>
> Из относительно чистых — можно попробовтаь скачать Turbo Pascal 1.0 —
> едва ли там много чего добавить успе Кан тoгда
В режим турбо паскаля Free Pascal Compiler загнать можно.

Здравствуйте, Аноним, Вы писали.

Сейчас пытаюсь изучить схему по scip.
Видимо, моей ошибкой при разборе злых примеров и выполнении упражнений были попытки представить рекурсию в уме.
Не делайте этого без бумажки!

Или это у меня с абстрактным мышлением что-то не в порядке?

Здравствуйте, last shinji, Вы писали:

LS>Сейчас пытаюсь изучить схему по scip.
LS>Видимо, моей ошибкой при разборе злых примеров и выполнении упражнений были попытки представить рекурсию в уме.
LS>Не делайте этого без бумажки!

Да на первых порах и императивную программу без бумажки трудно представить. А потом...

LS>Или это у меня с абстрактным мышлением что-то не в порядке?

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

Здравствуйте, konsoletyper, Вы писали:

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

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

Довольно сложно представить в уме рекурсию такого рода:

(define (permutations s) (if (null? s) 
                             (flatmap (lambda (x)
                                        (map (lambda (p) (cons x p))
                                             (permutations (remove x s))))
                                      s)))

а на бумажке лень >_<.

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

Здравствуйте, last shinji, Вы писали:

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

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

Смотря что понимать под "осознанием". Если имеется ввиду некоторая последовательность исполнения инструкций на уровне операций с элементами списка — то, ИМХО, это рецедив императивного мышления. Но, естественно, нужно понимать что твориться в программе: ага, вот тут map — это значит, что функция, переданная как первый аргумент, применится к каждому элементу списка и породит список результатов применений; ну и т.д.

Мне кажется, здесь лучше "думать" на уровне списков, а не их элементов: выполнили что-то над данным списком и вызвали ту же самую обработку для подсписков на 1 элемент короче, обеспечив правильную "подклейку" результатов этих новых вызовов.

(Блин, сколько в Лиспе скобок (только не бейте, дяденьки))

Почти точное повторение приведённой SICPовской реализации на Хаскелле

permutations :: Eq a => [a] -> [[a]]
permutations [] = [[]]
permutations xs = concatMap (\x -> map (\ys -> x : ys) (permutations (remove x xs))) xs
                    where 
                      remove u us = filter (\x -> x /= u) us
-- concatMap это flatmap, [] это nil, : это cons (в инфиксной форме)
-- remove взят со следующий страницы SICP и хаскеллизован

Внутренние лямбды заменяем сечениями, а избыточные скобки — инфиксным оператором $ (задаёт низкий приоритет для применения функции):

permutations xs = concatMap (\x -> map (x :) $ permutations $ remove x xs) xs
                    where 
                       remove u us = filter (/= u) us

Видим, что remove ни фига не сокращает запись; избавляемся от него:

permutations xs = concatMap (\x -> map (x :) $ permutations $ filter (/= x) xs) xs

Я чуствую, что Трурль бы пошёл дальше в этом, как его, рефакторинге, что ли? О, придумал: рехаскеллинге. И сделал бы permutations полную анлямбду.

Кстати, этот SICPовский permutations странненько будет работать на списке с повторяющимися элементами (из-за того, что remove убирает не 1 элемент, а все элементы с данным значением).

Трурль, наверное, спит; сделаю сам

permutations [] = [[]]
permutations xs = concatMap (permWithFirst xs) xs
                  where
                    -- возвращает все пермутации xs с отброшенным x, а затем
                    -- добавляет этот x в начало каждой пермутации
                    permWithFirst xs x = map (x:) $ permutations $ filter (/=x) xs

Здравствуйте, R.K., Вы писали:

RK>perm [] = [[]]
RK>perm (x:xs) = [ps ++ x:qs | rs <- perm xs, (ps,qs) <- splits rs]

Ага! Чтобы получить все перестановки x:xs делаем так:
Берём все перестановки xs (это rs), нарезаем их по-всякому (splits), и засовываем x между левым и правым обрезками (ps ++ x:qs).
Класс. Компрехеншен — сила!

RK>-- эквивалент splits xs = inits xs `zip` tails xs
RK>splits xxs@(x:xs) = ([], xxs) : [(x:ps, qs) | (ps,qs) <- splits xs]

A inits и tails — это будут

inits [] = [[]]
inits (x:xs) = [[]] ++ [x:ys | ys <- inits xs]

tails [] = [[]]
tails xxs@(x:xs) = xxs:[ys | ys <- tails xs]

Здравствуйте, R.K., Вы писали:
RK>С ремувами и фильтрами неэффективно и не слишком красиво получается. Вот вариант перестановок получше:
RK>

RK>perm [] = [[]]
RK>perm (x:xs) = [ps ++ x:qs | rs <- perm xs, (ps,qs) <- splits rs]

RK>-- эквивалент splits xs = inits xs `zip` tails xs
RK>splits [] = [([], [])]
RK>splits xxs@(x:xs) = ([], xxs) : [(x:ps, qs) | (ps,qs) <- splits xs]
RK>

Класс!
Переписал на python получилось только немного длиннее:

def split(xxs):
  if not xxs:
    return [([], [])]
  return [([], xxs)] + [([xxs[0]] + ps, qs) for ps, qs in split(xxs[1:])]

def perm(xxs):
  if not xxs:
    return [[]]
  return [ps + [xxs[0]] + qs for rs in perm(xxs[1:]) for ps, qs in split(rs)]

А вот если попытаться работать с итераторами и генераторами, получается уже не так лаконично:

def split2(xxs):
  xs, xxs = itertools.tee(iter(xxs))
  try:
    x = xs.next()
    yield [], list(xxs)
    for ps, qs in split2(xs):
      yield [x] + ps, qs
  except StopIteration:
    yield [], []

def perm5(xs):
  xs = iter(xs)
  try:
    x = xs.next()
    for rs in perm5(xs):
      for ps, qs in split2(rs):
        yield ps + [x] + qs
  except StopIteration:
    yield []

Хотя ленивость иногда стоит того!

Здравствуйте, Tonal-, Вы писали:
T>Хотя ленивость иногда стоит того!

А в python ленивость — через yield'ы?

Здравствуйте, R.K., Вы писали:

RK>Еще интересная задача сделать перестановки с учетом повторяющихся элементов. Функция perm' должна принимать на вход список списков, полученных от group(By) и возвращать список пермутаций без повторений. Например:
RK>

>> perm' $ group "aabc"
RK>["aabc","aacb","abac","abca","acab","acba","baac","baca","bcaa","caab","caba","cbaa"]
RK>

Не совсем понял про group — это множество всех (не?)упорядоченных подмножеств?
group "ab" даст ["","a","b","ab"]? Или ["","a","b","ab","ba"]?

Вообще решение в лоб — выкинуть повторяющиеся элементы, написав функцию uniq

uniq $ perm "aabc"

но оно, очевидно, не самое эффективное.
Вечером подумаю.

Здравствуйте, deniok, Вы писали:

D>Не совсем понял про group — это множество всех (не?)упорядоченных подмножеств?
D>group "ab" даст ["","a","b","ab"]? Или ["","a","b","ab","ba"]?

inits, tails, group — все из модуля List. group выделяет соседние повторяющиеся элементы:

> group "aabc"
["aa","b","c"]
> :t group
group :: (Eq a) => [a] -> [[a]]
-- groupBy аналогична sortBy
> :t groupBy
groupBy :: (a -> a -> Bool) -> [a] -> [[a]]

D>Вообще решение в лоб — выкинуть повторяющиеся элементы, написав функцию uniq
D>

D>uniq $ perm "aabc"
D>

Ага, и такая функция уже есть в List: nub

D>но оно, очевидно, не самое эффективное.

Здравствуйте, R.K., Вы писали:

RK>inits, tails, group — все из модуля List. group выделяет соседние повторяющиеся элементы:
RK>Ага, и такая функция уже есть в List: nub

Ну серый я, как штаны пожарника. Мне казалось, что там из "разумного" только sort и zipы с большими номерами

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Cyberax, Вы писали:

C>>Причем, почему-то схемисты и лисповоды — самые ярые противники XML.

А>Так понятно почему. Из-за синтаксического оверхеда.

А>

А>(+ a b)
А>

А>vs.
А>

А><plus>
А>    <a />
А>    <b />
А></plus>

А>

Наверно жутко мучаешься когда вместо инфиксной записи операторов пишешь название функции перед списком аргументов (func x1 x2 x3)?

Здравствуйте, dr.Chaos, Вы писали:


DC>Наверно жутко мучаешься когда вместо инфиксной записи операторов пишешь название функции перед списком аргументов (func x1 x2 x3)?

Да какие, блин, еще мучения. Что там такого мучительного-то?
Вообще же, хочу сказать, operator precedence parser — это максимум 10 строчек в виде макро и любые операторы с любыми приоритетами в результате, в отличие от "обычных" языков.
Только, разумеется, после некоторой практики, потребность в этом сама отпадает.
Во-первых, более-менее серьезное программирование — это не простые арифметические выражения и циклы. Это коллекции и их трансформации.
Ну типа возможность писать так ценнее всяких приоритетов:

> (map + '(1 2 3) '(4 5 6))
(5 7 9)

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

> (+ 1 2 3 4 5)
15

Примеры, для простоты, на Scheme

Здравствуйте, Аноним, Вы писали:

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

Ладно проехали.

Здравствуйте, R.K., Вы писали:


RK>Вечер — понятие сильно растяжимое.


RK>

RK>-- perm' принимает список после group(By)
RK>perm' [] = [[]]
RK>perm' xs = intern' xs
RK>    where
RK>    intern' = concatMap (uncurry intern) . splits'
RK>    intern [] [[q]] = [[q]]
RK>    intern ps ((q:qs'):qs) = map (q:) $ intern' $ (ps++) $ case qs' of
RK>        [] -> qs
RK>        _ -> qs':qs

RK>-- splits' это splits без последнего элемента
RK>splits' xs@[_] = [([], xs)]
RK>splits' xxs@(x:xs) = ([], xxs) : [(x:ps, qs) | (ps,qs) <- splits' xs]
RK>

Вроде понял. intern, приняв, скажем ["a","b"] ["cc","d"], отщепляет первую c и гонит в начало, а остальное собираем в список и снова intern'. Назвать бы их (intern и intern') по-человечески. Вообще, механизм немного похож на мою версию permutations, которая с фильтрами. Там, где у меня была фильтрация, здесь — пересборка списка без q.

А splits' без последнего элемента — это чтобы в intern' образец ((q:qs'):qs) был неопровержим.

Здравствуйте, R.K., Вы писали:


RK>На все имен не напридумываешь. Эти же функции суть просто тело внешней, а имена им даны только для их рекурсивного вызова. Ну с фильтрами таки был лишний прогон с пересозданием списка во внутреннем цикле, а тут просто конкатенация — есть слабая надежда, что компилятор извернется и соптимизирует Еще предикат в фильтре дает совершенно лишнее ограничение на Eq типа элементов списка.

Понятно, что с фильтрами алгоритм дурной. Я просто перетаскивал на Хаскелл алгоритм из SICP.

Почему-то у меня никак не получается понять, как работает функция обращения списка с присаваинванием.
При попытке представить это у меня получается (d c d b c d a b c d), а вовсе не (a b c d).
Возможно я упускаю какую-то деталь, связанную с окружениями, или с тем как представляются списки (как мне показалось, в книге с представлением списков существует некоторый разброд).
Натолкните пожалуйста на верный путь.

(define (mystery x)
  (define (loop x y)
    (if (null? x)
        y
        (let ((temp (cdr x)))
          (set-cdr! x y)
          (loop temp x))))
  (loop x '()))

(define v (list 'a 'b 'c 'd))

(mystery v)

Здравствуйте, Curufinwe, Вы писали:

C>В каждой итерации берётся голова первого списка и делается головой второго:
C>(let ((temp (cdr x))) — запоминаем хвост 1 списка
C> (set-cdr! x y) — голова 1 списка + 2 список
C> (loop temp x)))) — повторяем итерацию. При первом рекурсивном вызове: temp = (b c d), x = (a), для второго: temp = (c d), x = (b a) и т.д.

Спасибо, я невнимательно отнесся к тому, что делает операция set-cdr!.

Во наобсуждали. Зашёл сюда случайно.
Сейчас в магазине есть книжка по Haskell на русском языке:

Душкин Р.В. Функциональное программирование на языке Haskell.


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