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

U>У тебя с пониманием русского языка как? Как после "происходит сброс кэша" может быть нужен "ручной сброс кэша"?
У меня — нормально. У вас вот, похоже, какие-то затруднения с восприятием. Слова "ручной" в моём сообщении нет и не было.
Поясню на всякий случай: в задачу не входит понятие кэша. В задачу входит какая-то прикладная вещь, типа построение сервиса для аренды недвижимости. И вот оказывается, что если писать сервис так, чтобы используемые методы HTTP соответствовали природе выполняемых запросов, то всё волшебным образом работает, и работает эффективно.

Не надо думать "как бы мне так сбросить кэш при выполнении запроса ConfirmApartmentBooking". Этот вопрос уводит нас в сторону от корректной и надёжной реализации. Надо думать "является ли запрос ConfirmApartmentBooking идемпотентным или безопасным"? И выбирать метод исходя из этого.

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

S>Здравствуйте, Шахтер, Вы писали:

Ш>>Я знаю, что такое поле Галуа, я спросил, что такое "алгебра полей Галуа".
Ш>>Правильный ответ -- это произвольная комбинация слов.
S>Гм. Я, возможно, как-то неправильно употребляю термины. Но с моей, непрофессиональной точки зрения, поле Галуа — это алгебраическая система. Именно але

Ладно, спишем это на плохой французский.

Ш>>Я спрашивал, какое отношение БПФ имеет к полям Галуа.
Ш>>Правильный ответ -- никакого.
S>Почему же? Если верить википедии, Many FFT algorithms only depend on the fact that is an Nth primitive root of unity, and thus can be applied to analogous transforms over any finite field. То есть их можно применять к аналогичным преобразованиям над произвольными полями Галуа.

Это разные вещи.
Сам по себе алгоритм (а лучше сказать алгоритмы, потому что их целое семейство) FFT никакой связи с полями Галуа не имеет.
Нет никаких особых свойств полей Галуа, которые приводят к существованию этого алгоритма. Ни его формулировка, ни доказательство его свойств никоим образом не используют теорию полей Галуа.
То что применять этот алгоритм можно не только к комплексным числам, а и в гораздо более общей ситуации (но опять же, далеко не всегда, не во всяком поле Галуа можно сделать преобразование Фурье, только при определённых условиях) вовсе не означает что цитирую, "Быстрое Преобразование Фурье построено на алгебре полей Галуа".

Ш>>Совсем тяжелый случай. ООП не имеет каких-то математических основ. Совсем.
S>А вы пробовали читать по ссылке?

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

Вот простой пример для контраста. В современной радиосвязи широко применяется технология OFDM. Эта технология имеет математическую основу -- FFT. Т.е. сначала бы придуман алгоритм, потом на его основе был придуман способ модуляции сигнала.

Копай Нео, копай -- летать научишься. © Matrix. Парадоксы

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

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

Ш>Это разные вещи.
Ш>Сам по себе алгоритм (а лучше сказать алгоритмы, потому что их целое семейство) FFT никакой связи с полями Галуа не имеет.
Ш>Нет никаких особых свойств полей Галуа, которые приводят к существованию этого алгоритма. Ни его формулировка, ни доказательство его свойств никоим образом не используют теорию полей Галуа.
Ну хорошо. Расскажите тогда своими словами, на каких свойствах каких алгебраических систем построен алгоритм Кули-Тьюки.

Ш>То что применять этот алгоритм можно не только к комплексным числам, а и в гораздо более общей ситуации (но опять же, далеко не всегда, не во всяком поле Галуа можно сделать преобразование Фурье, только при определённых условиях) вовсе не означает что цитирую, "Быстрое Преобразование Фурье построено на алгебре полей Галуа".

Ш>Вот простой пример для контраста. В современной радиосвязи широко применяется технология OFDM. Эта технология имеет математическую основу -- FFT. Т.е. сначала бы придуман алгоритм, потом на его основе был придуман способ модуляции сигнала.

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

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

S>б) приводят данные в одно и то же целевое состояние при повторном выполнении

К примеру, list.Remove(obj) является идемпотентной операций, list.RemoveAt(index) — нет. Но на практике эта разница мало интересна, т.к. строит логику таким образом, что в ней возможны лишние вызовы Remove это мягко говоря извращение, вне зависимости от идемпотентности этого вызова.

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

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

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

U>К примеру, list.Remove(obj) является идемпотентной операций, list.RemoveAt(index) — нет. Но на практике эта разница мало интересна, т.к. строит логику таким образом, что в ней возможны лишние вызовы Remove это мягко говоря извращение, вне зависимости от идемпотентности этого вызова.
Эта разница малоинтересна в том малоинтересном случае, когда вызовы list.Remove() гарантированно завершаются.
В случае вызова удалённой системы у нас такой гарантии нет. То, что при выполнении метода случился таймаут, ничего не говорит нам о том, что произошло на вызываемой стороне. Возможно, до неё вызов так и не дошёл; возможно — до нас не дошло подтверждение.
Поэтому идемпотентность операций крайне важна в распределённой среде.

U>Как раз все наоборот. Объяснение с использованием кэша это описание механизма работы http, т.е. его образное представление (возможно в данном виде не совсем верная, т.к. я с http не работаю и соответственно его не знаю) и соответственно его понимание. Ты же просто приписываешь http командам набор признаков (идемпотентность в частности) не раскрывая механизма объясняющего почему это важно.
Я не претендую заменить собой весь учебник. Я всего лишь приводил примеры математики в программировании. При этом я не знаю, на какой уровень вашей подготовки в предмете надо рассчитывать.
Если вы хотите чему-то научиться — спрашивайте, я объясню подробнее. Пока что вы больше хамите.

U>Практики в среднем объясняют гораздо лучше, т.к. в первую очередь дают образное представление происходящего.
Вот как раз я и есть практик. Вы думаете, я все эти вещи глядя на звёзды придумал? Нет, изучил собственным горьким опытом. Ещё раз подчеркну: образное представление не может заменить точных знаний.

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

AVK>Главное требование к синтаксису языка — легкая читаемость. А она, в свою очередь, сильно зависит от традиций. И так уж сложилось, что подавляющее число программистов лучше всего воспринимают c/паскаль подобный синтаксис. Вот соответствие этому синтаксису, имхо, как раз и можно расценивать как преимущество.

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

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

S>Поэтому идемпотентность операций крайне важна в распределённой среде.

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

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

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

Здравствуйте, Паблик Морозов, Вы писали:

ПМ>Подавляющее большинство программистов не лучше воспринимают c/паскаль подобный синтаксис, подавляющее большинство ничего не знают, кроме си/паскаля. Это немного разные вещи.

Они может и разные, но в контексте разговора разницы нет.

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

U>К примеру, list.Remove(obj) является идемпотентной операций
В общем случае не является и идемпотентность операции зависит от отношения эквивалентности объектов, которое достаточно математично (рефлексивность, транзитивность, симметричность), что бы о нем не забыть в этом топике.

var list = new List<object> { 0, 0, 0 };
object obj = 0;
list.Remove(obj);
list.Remove(obj);

U>, list.RemoveAt(index) — нет. Но на практике эта разница мало интересна, т.к. строит логику таким образом, что в ней возможны лишние вызовы Remove это мягко говоря извращение, вне зависимости от идемпотентности этого вызова.
Идемпотентность в отношении списка мало интересна, а вот корректное переопределение Equals — вполне должно интересовать программиста.

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

U>В случае распределенной системы и соответственно возможности параллельных изменений говорить о сферической идемпотентности в вакууме вообще не имеет смысла. Т.к. если в протоколе указывается к какой версии данных применяется преобразование, то любая модифицирующая операция становится идемпотентной, т.к. ее повторный вызов будет отброшен сервером из-за несоответствия версий. Если же контроль версии данных не производится, то любая модифицирующая операция не является идемпотентной, т.к. повторный вызов может затереть параллельные изменения произошедшие после первого вызова.
Ну вот видите, как здорово — стоит немножко задуматься о математической стороне дела, и сразу происходит существенный прогресс. А "образное мышление" привело к тому, рынок наводнили API без малейшего представления о версионировании, идемпотентности и прочих умных вещах. Только теперь (буквально в последние три года) внезапно появился REST, который вы только что изобрели "в прямом эфире". Вам для этого хватило два дня обсуждений малознакомого вам протокола. Образно мыслящей общественности потребовалось пятнадцать лет интенсивной половой жизни с XML-RPC, SOAP и прочими противоестественными архитектурами.

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

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

M>Если это софт для какой-нить АЭС

Я все ждал, когда ж подтянутся программисты АЭС.

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

S>Образно мыслящей общественности потребовалось пятнадцать лет интенсивной половой жизни с XML-RPC, SOAP и прочими противоестественными архитектурами.
/Offtopic: хочу взять бензопилу и разрезать нафиг всех пропонентов REST на кусочки не больше одного кубического сантиметра.

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

C>/Offtopic: хочу взять бензопилу и разрезать нафиг всех пропонентов REST на кусочки не больше одного кубического сантиметра.
А что конкретно вас беспокоит в REST?

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

M>>Если это софт для какой-нить АЭС

AVK>Я все ждал, когда ж подтянутся программисты АЭС.

Это образно, но доказетельство корректности алгоритмов иногда таки требовалось.

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

C>>/Offtopic: хочу взять бензопилу и разрезать нафиг всех пропонентов REST на кусочки не больше одного кубического сантиметра.
S>А что конкретно вас беспокоит в REST?
Многое.
1) Внешний мир не идемпотентен.
2) Нет возможности нормально делать диалоги — их приходится всё время эмулировать. Криво. Это самое бесящее.
3) Технические ограничения GET-запросов, которыми предлагается делать идемпотентные действия. POST'ы спасают, но по идеологии REST они должны использоваться для действий.
4) Caching is overrated.
5) При использовании версированного API — проблемы с устареванием данных.

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


C>Многое.
C>1) Внешний мир не идемпотентен.
Этого не понял.
C>2) Нет возможности нормально делать диалоги — их приходится всё время эмулировать. Криво. Это самое бесящее.
Не очень понятно, что такое "диалоги". Вас интересует stateful сессия? Да, её приходится эмулировать.
Это оборотная сторона REST. Зато эти сессии появляются только там, где необходимо, а не там, где случайно получилось.

C>3) Технические ограничения GET-запросов, которыми предлагается делать идемпотентные действия. POST'ы спасают, но по идеологии REST они должны использоваться для действий.
Да, это кагбэ такая неприличная подробность, о которой не принято говорить. Но она вызвана не природой REST, а косяками конкретных реализаций протокола HTTP. Если вы пишете свой сервер, то особых ограничений в GET-запросах нет: хоть видеофайл в строке передавай.
Для более реалистичных сценариев можно использовать идемпотентный PUT.
C>4) Caching is overrated.
Когда как.
C>5) При использовании версированного API — проблемы с устареванием данных.
Не очень понятно, как проблемы с устареванием данных связаны с API. API с версионированием всего лишь позволяет обнаружить факт устаревания.

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

C>>2) Нет возможности нормально делать диалоги — их приходится всё время эмулировать. Криво. Это самое бесящее.
S>Не очень понятно, что такое "диалоги". Вас интересует stateful сессия? Да, её приходится эмулировать.
S>Это оборотная сторона REST. Зато эти сессии появляются только там, где необходимо, а не там, где случайно получилось.
Вот ситуация — надо создать документ. В одном экземпляре.

Попытка номер 1 — POST-метод. Не работает — если теряем соединение после окончания метода, то у нас потеря документа.
Попытка номер 2 — POST-метод с уникальным GUID'ом для tracking'а, передаваемым в запросе. Не работает из-за вопросов безопасности.
Попытка номер 3 — разбиваем на два этапа: получение уникального GUID'а первым запросом, а потом использование этого GUID'а во втором.

Получается криво.

C>>3) Технические ограничения GET-запросов, которыми предлагается делать идемпотентные действия. POST'ы спасают, но по идеологии REST они должны использоваться для действий.
S>Да, это кагбэ такая неприличная подробность, о которой не принято говорить. Но она вызвана не природой REST, а косяками конкретных реализаций протокола HTTP. Если вы пишете свой сервер, то особых ограничений в GET-запросах нет: хоть видеофайл в строке передавай.
S>Для более реалистичных сценариев можно использовать идемпотентный PUT.
А ещё из практических встреч — проблемы с кодировками запросов.

C>>5) При использовании версированного API — проблемы с устареванием данных.
S>Не очень понятно, как проблемы с устареванием данных связаны с API. API с версионированием всего лишь позволяет обнаружить факт устаревания.
Ну и что дальше делать? Получается, что надо темпоральную базу иметь чуть ли не для всех доменных объектов при богатом REST-API. Или кидать в таком случае исключения, что не есть хорошо — блокировок нет, а сценарии с оптимистической блокировкой без атомарности получаются жуткими.

Добавлю ещё:
6) Отсутствие само-описания типа WSDL для SOAP.
7) Нет формальной спецификации — каждый понимает REST по-своему. Из-за этого, клиент практически для любого сервиса приходится писать после долгого вкуривания документации и экспериментов. Для SOAP уже всё почти plug&play — я могу взять WSDL, по ней сгенерировать стабы и использовать в почти любом языке.
8) Проблема с передачей сложных данных (даже банальный hash map нормально не передаётся) и т.д. Я понимаю, что сразу в таких случаях кричат: "JSON в POST/PUT", но в чём тогда отличие от SOAP?

Офигительно ограниченное API.

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

C>Добавлю ещё:
C>6) Отсутствие само-описания типа WSDL для SOAP.
А WADL? Оно, конечно, не широкоупотребимо, но как вариант...

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

C>>Добавлю ещё:
C>>6) Отсутствие само-описания типа WSDL для SOAP.
К>А WADL? Оно, конечно, не широкоупотребимо, но как вариант...
Это даже не стандарт ещё. Для JSON до сих пор тоже аналога XSD нормального нет — есть json-schema, но опять же, поддержка нулевая.

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

M>Это образно

В лес такие образы. В каком то форуме было правило, как только в топике упоминается Гитлер, топик сразу можно закрывать. В программистских флеймах полный аналог Гитлера — программирование АЭС.