SiemarglGluk (Kazan),

Не МУМПС, который и так почти дохлый, а идея доступа к данным из программы. Хорошо, начнем с другого конца=)

Как, по вашему, должны хранить данные _большие_ программы на ФП?

В БД (они знаете ли очень для этого подходят)
а по вашему ???

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

Там не распараллеливание, а оптимизация в полный рост.
И не за счет декларативности, а за счет узкой сцепифичности задачи

Siemargl
2. Как БД соотнесутся с ФП - вообще неизвестно, ибо в ФП отрицается сама идея состояний и постоянного хранения данных вычислений (((


Зато БД прекрасно соотносятся с прикладными задачами, которые приходиться решать и ФП в том числе. Кстати, никто не отрицает необходимости долгосрочного хранения состояния. Что касается необходимости хранения оперативного состояния, на кой по вашему пришлось изобретать монады ???

Есть такая необходимость. И существование этой необходимости куда более определяющее, чем отношение к ней ФП. Практика - критерий истины ? ;)

Nitro_Junkie
Нифига себе узко-специфичная задача - все бизнес-решения и информационные системы :) Кроме того императивный алгоритм (то есть с if, while) по количеству абстракций проще чем SQL. А хорошо оптимизируется почему-то последний.

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

А бизнес-решения кстати пишутся не на SQL, а на универсальных ЯП (C# например или PL/SQL), SQL для этого совершенно очевидно недостаточен.

Когда Вы говорите, у меня такое впечатление, что вы бредите (c)

Nitro_Junkie
А можно узнать что вы имеете ввиду под универсальным языком программирования? Полнотой по Тьюрингу он обладает.


Доказательство полноты по Тьюрингу будет ?
Про какой SQL говорим ? Фраза MODEL Oracle ???

Nitro_Junkie
Да, он меньше подходит под одни задачи (UI на нем тяжело запрограммировать), но хорошо подходит под другие... Строго говоря UI делать и на if'ах и while'ах без вспомогательных библиотек (неважно в какой парадигме) также невозможно.


тяжело ? т.е. возможно ??? Валяй, интересно будет посмотреть
Наверное системное программирование на SQL это тоже тяжело ???
SQL это в чистом виде DSL, придуманный когда самого термина DSL еще небыло. Это проблемнно-ориентированный язык, а не язык программирования

Nitro_Junkie
В любом случае вы почему-то считаете что SQL проще структурного кода, что явно не так. Грамматика первого состоит где-то из правил 5-10, а грамматика второго в несколько раз больше.

Не понел ? Из с чего вообще взялось сравнение проще-сложнее ???
Грамматику чего с чем меряем ???
Как будем поступать с семантикой ?

Nitro_JunkieGluk (Kazan),
SQL - 1999 (с появлением рекурсивных CTE), полон по тьюрингу, легко построить отображение на частично-рекурсивные функции... уже обсуждалось, не будем повторяться, гугл в помощь...


Если сто раз сказать мед, сладко не станет
Доказательства полноты по Тьюрингу в студию (только доказательства, а не домыслы, как в прошлый раз). И не сферического CTE, а конкретной реализации CTE

Nitro_Junkie
Грамматику SQL, с грамматикой структурного программирования по количеству правил. А уж семантика структурного программирования так точно проще семантики SQL... Но нет последний все равно лучше оптимизируется...

Давай с этого места поподробнее. Что такое грамматика и семантика "структурного программирования" ??? PL/I аль Си имеешь в виду ??? Али Пасквиль с Адой ?

Впрочем, грамматики в студию, пустозвон вы наш, строки считать бум

Nitro_JunkieGluk (Kazan),

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

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

1. Реализацию машины Тьюринга на SQL (коея как правило и принимается за доказательство (не знал ? будешь знать ))
2. Ссылки на грамматики SQL и ... скажем C++ :) не буду тебя на PL/I посылать. С целью сравнения их объема.

А в ответ бла бла бла, уши вянут. Найдешь приходи. Хоть в отдельную тему, хоть ко мне в почту.
А здесь с SQL-ем больше не мелькай, надоело

Nitro_Junkie
1. Для доказательства полноты по Тьюрингу, достаточно показать эквивалентность одному из множеств вычислимых функций. И для декларативных формализмов, это проще делать сравнивая с частично-рекурсивными функциями для которых уже доказана полнота по тьюрингу.

1. Валяй, так тоже можно. Жду доказательство
2. И не забудь про грамматики :) жду ссылок на то что будем сравнивать (чтобы потом не отперся)

Nitro_JunkieКстати с какого боку тут C++, максимум C и то без дополнительных наворотов типа макросов и т.п. If, while, массивы, операторы присваивания, сравнения, функции и может struct'ы.

Странно :) А почему не PL/I ??? SQL то Вы самый навороченный предлагаете взять, а язык уровня 70 года. Ай яй яй.

beluginGluk (Kazan)А Вам новичков почти удалось ввести в заблуждение.

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

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