great propaganda

[juan_gandhi]

IP is doomed

Comments

[tzirechnoy.livejournal.com]

А ты за большэвиков или за коммунистов Verilog -- он императивный или функцыональный?

[spamsink.livejournal.com]

Стоит вечерком в цирк отлучиться - опережают почем зря!

[kika.livejournal.com]

"нечистый" функциональный, насколько я про него что-то помню (а это типа лет 20 назад). То есть с побочными эффектами.

[antonyc.livejournal.com]

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

[sorhed.livejournal.com]

Проект — любой, язык — любой. Что больше нравится.

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

Можно, конечно, тупо решать задачки с Project Euler, но предпочитаю что-нибудь более приземлённое.

[trurle.livejournal.com]

Когда мне было 16 лет, я читал ровно такие же тексты, но там вместо многоядерных процессоров были симметрично-мультипроцессорные системы, а вместо Хаскелля и Эрланга - Пролог.

[orleanz.livejournal.com]

" или всё что угодно на скале.

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

[sorhed.livejournal.com]

Я думал, вы просто хотите научиться функциональному программированию, а не ищете высокопараллельную задачу. В моей области (финансы) таких задач полно. Но, например, web spider — вполне себе toy project для этой области, хотя тут скорее concurrency, чем parallelism. Ну или любая задача из image processing — процессоров на компьютере сейчас, чай, больше одного.

[jakobz.livejournal.com]

В упор не понимаю чего они так привязались к этой concurency, и еще ФП как панацею преподносят. Там же CAP с одной стороны и ФП тут не поможет, а с другой стороны у всех все нормально и без ФП живет.

[bytebuster463.livejournal.com]

Задача обязательно должна быть. Вот, для примера берёте любую задачу отсюда и выполняете по мере сил. Если упираетесь в проблему, качаете чьи-то решения и смотрите, как это сделали те, кто уже умеет.
http://users.livejournal.com/_darkus_/646993.html

[vaddimka.livejournal.com]

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

[jakobz.livejournal.com]

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

Короче если у тебя два запроса обрабатываются параллельно - у тебя одна и та же проблема что в дотнетах, что в хаскеле. Да и вообще везде тоже самое с concurency - что в дотнетах, что в хаскелях.

[nponeccop.livejournal.com]

комментарии доставляют

[nponeccop.livejournal.com]

не у всех

[sassa-nf.livejournal.com]

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

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

а вот CPS открывает новые возможности. я даже не о message passing (который я почему-то не вижу как что-то концептуально отличающееся от лока).

[nine_k]

SMP и правда вокруг тучами. А вот пролог непонятно с какой стороны для них лучше подходит, чем C или там Go.

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

[nine_k]

Да легко. Счётчик — это бесконечный ленивый immutable список целых, возрастающих на 1.

А вот как реализовать счётчик параллельно выполняющихся запросов — гораздо смешнее вопрос. Вроде как CAP-теорема накладывает на него ограничения. Как их решают в БД (где sequences), я, например, не в курсе; кажется, иногда кэшированием кусков и пропуском значений. Есть ли красивре FP-решение для сериализации, не знаю.

[sassa-nf.livejournal.com]

sequence не является счётчиком.

CAP не накладывает ограничения на счётчик. ограничения на счётчик накладывает ACID.

[odrdo.livejournal.com]

Но, при использовании MVar, в типе функции всегда будет видно, что она IO.
А также в функции, которая вызывает эту функцию и т.п.
Не знаю дотнета, но сомневаюсь, что в C# это так.

С concerrency сложности не пропадают, конечно, но какая-то помощь от языка и компилятора появляется.

Исходный текст про параллельные вычисления я бы рассматривал как декларацию о "нише" (kill-app), а не как описание всех преимуществ H и FP. Ну, может о том, как автор пришел к FP. Преимуществ и применений Haskell гораздо больше. Совсем не обязательно параллельностями заниматься...

[nine_k]

Ну, в Oracle или Postgres sequence гарантирует, что выдаёт строго возрастающие числа, в сколь угодно параллельных запросах. Оно вроде бы шага строго в 1 не гарантирует, он обычно обеспечивает.

Про CAP и ACID согласен, погорячился.

[jakobz.livejournal.com]

Так я как раз и негодую за то, что как только начинается разговор про ФП - сразу приплетают concurency и преподносят ФП как панацею. А про остальное как-то мимо.

Ну и вот это вот:
>There are no data races in purely functional languages because they don’t have mutable variables.

- наглая ложь же

[odrdo.livejournal.com]

А где здесь ложь, в посылке или в следствии?

[jakobz.livejournal.com]

В посылке. Все ФП-языки имеют mutable state, без него просто два потока просто не смогут общаться. Ну и гонки и дедлоки - тоже будут.

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

[thesz.livejournal.com]

>Но что прям вот нет гонок - это ложь.

MVar их не имеет, STM тоже.

Дедлоки у меня возникали при определении тишины в канале. Это не считается.

[jakobz.livejournal.com]

Одна переменная, обернутая в lock {} - тоже не имеет ни гонок, ни дедлоков.

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

Понятно что так стараются не делать в Хаскеле, и сплошь и рядом делают в дотнетах. Но это в большей мере только потому что в ФП народ сообращает круче.

[sassa-nf.livejournal.com]

оппа, как это - строго возрастающие числа в параллельных запросах? ;-)

на самом деле sequence - это инструмент линеаризации обозреваемости committed транзакций.

[sassa-nf.livejournal.com]

"STM тоже"

ну и? там, где без STM может быть race condition, там с STM будет lack of progress (redo).

[nine_k]

Как — понятно: отдельный синхронный механизм (опционально). У оракла, по кр. мере.

Specify ORDER to guarantee that sequence numbers are generated in order of request. This clause is useful if you are using the sequence numbers as timestamps. Guaranteeing order is usually not important for sequences used to generate primary keys.

ORDER is necessary only to guarantee ordered generation if you are using Oracle Database with Real Application Clusters. If you are using exclusive mode, sequence numbers are always generated in order.

В другом месте они приямо говорят: "Selecting the ORDER option ensures that each NEXTVAL request across the cluster will be synchronized so that usage is chronologically ordered. This is achieved by having all sessions share a single cache for this sequence. Each reference to NEXTVAL will involve a lock request to claim a new value".

Понятно, что для линеаризации в рамках одной сессии достаточно NOORDER и просто неповторяющихся чисел.

[sassa-nf.livejournal.com]

Да я не об этом. Если запросы параллельные, как можно говорить о "строго возрастающих" числах? Иными словами, время commit параллельных запросов не определяется "строго возрастающим" числом.

"Строго возрастающее" число определяет, какие транзакции вы будете обозревать. Если у вас два типа транзакций - одни читают X и модифицируют Y, другие дописывают новые строки в X, в ACID нет ничего, что бы заставляло транзакции первого типа обозревать какие-либо изменения в X вообще.

[sassa-nf.livejournal.com]

и второе. "строго возрастающее" число может не обозреваться таким, ибо не все транзакции commit - какие-то будут rollback.

[odrdo.livejournal.com]

mutable state /= mutable variable.
Т.е., формально, мне не кажется, что там ложь.

Скорее уж "умалчивание о проблемах", "great propaganda"...

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