Почему изменяемое состояние это плохо?
Неявность. Ничего другого в голову не приходит.
Чем плохо изменяемое состояние?сложностью композиции..
если есть код А, решающий задачу P1 и код B, решающий задачу P2, то нет гарантии (сложно предсказать что код A+B сможет решить задачу P1+P2
код A+Bчто это такое? Например, код с двумя функциями Main даже не компилируется.
что это такое?Операция суммирования двух кодов, заданная произвольным образом (с условием, что P(A+B)=P(A)+P(B где A, B - код, а P(x) - это набор задач, решаемые кодом x ). Основной подвох, что задать такую операцию конструктивным образом (через алгоритм построения) для кода с изменяемым состоянием очень и очень сложно.
код с двумя функциями Main даже не компилируетсяЭто обходится легко..
Или через общее правило, что если два кода при суммировании имеют пересекающиеся идентификаторы с разным смыслом, то заменить конфликтные идентификаторы на произвольные другие, которые еще не встречаются.
и/или через добавление аргумента, если через одну точку входа необходимо выполнять два несовпадающих функционала.
что это такое?обычно в качестве основы берется операция суммирования двух направленных графов с именованными вершинами (и код представляется в виде такого графа) со следующими правилами:
1. если вершины имеют одно и тоже название, и один и тот же подграф, "сформированный" исходящими дугами, то такие вершины сливаются в одну
2. если вершины имеют одно и тоже название, но разные подграфы, то перед выполнением п.3 конфликтные вершины переименовываются на новые уникальные названия
3. все остальные вершины копируется как есть из обоих исходных графов
Чем плохо изменяемое состояние?Ничем не плохо. Это субъективная вещь, обусловленная ограничениями человеческого восприятия - человек не в состоянии логически отследить последствия изменения слишком большого числа переменных, поэтому если состояний становится слишком много, код вырождается в говнокод.
Даркгрей как обычно попер в какую-то одному ему ведомую даль. Интересно, почему такие сложнейшие системы как человек, например, основанные на изменениях глобального состояния, не испытывают проблем с композицией. Отсюда вывод - проблема состояния исключительно артефакт человеческого мозга, супер мозг говнокодил бы совершенно иначе.
Интересно, почему такие сложнейшие системы как человек, например, основанные на изменениях глобального состояния, не испытывают проблем с композицией.да ну
не испытывают проблем с композицией.И как вставить человеку третью руку?
Вообще гипотетически довольно просто - нужно чуть подхимичить с гормонами на этапе эмбриона. Пользы от руки будет мало, но она отрастет.
Интересно, почему такие сложнейшие системы как человек, например, основанные на изменениях глобального состояния, не испытывают проблем с композицией.люди тоже проблемы испытывают. (Чудес не бывает, NP-сложность, она и для человека NP-сложность).
Из-за этих трудностей и вводятся в больших проектах запреты (ограничения) на глобальные переменные, вводятся модульные, компонентные, объектные парадигмы (или их аналоги придумываются паттерны и т.д. Всё это делается для того, чтобы изменяемое состояние ограничить в более предсказуемых рамках и свести проблему к задаче меньшего размера.
Даркгрей как обычно попер в какую-то одному ему ведомую даль. Интересно, почему такие сложнейшие системы как человек, например, основанные на изменениях глобального состояния, не испытывают проблем с композицией. Отсюда вывод - проблема состояния исключительно артефакт человеческого мозга, супер мозг говнокодил бы совершенно иначе.Перевожу пример даркгрея на понятный русский язык. Если ты проводишь пару по матану, занимая для этой цели аудиторию, и Вася проводит пару по терверу, занимая для этой цели аудиторию, то для того чтобы вы могли обучить вмкшников математике, вам нужен внешний компонент, который будет рулить расписанием по аудиториям, иначе будут конфликты. Если б можно было просто отдавать на вход курс произвольных студентов, а получать на выходе курс обученных матану студентов, всё было бы значительно проще.
Ну да, потому что люди ограничены и приходится разбивать состояние на мелкие части и организовывать все в деревья по сложности.
Ну да, потому что люди ограничены и приходится разбивать состояние на мелкие части и организовывать все в деревья по сложности.NP растет очень-очень быстро.
Соответственно, если супер-мозг будет даже в миллиарды разы круче, чем человек, то без внятных правил композиции/декомпозиции, он сможет решать задачи всего лишь раза в 3-10 больше.
Если ты проводишь пару по матану, занимая для этой цели аудиторию, и Вася проводит пару по терверу, занимая для этой цели аудиторию, то для того чтобы вы могли обучить вмкшников математике, вам нужен внешний компонент, который будет рулить расписанием по аудиториям, иначе будут конфликты. Если б можно было просто отдавать на вход курс произвольных студентов, а получать на выходе курс обученных матану студентов, всё было бы значительно прощеСовершенно необязательно иметь тут внешний компонент, есть немало способов решить эту проблему без него. Даже просто принцип кто первый встал, того и тапки сработал бы.
NP растет очень-очень быстро.Не понятно, причем тут НП. Пока что речь идет о скромных способностях человека - типа он может комбинировать 6 -7 сущностей + что-то (буквально мегабайт не больше) помнить о системе. Очевидно, искусственный интеллект теоретически способен на порядки превзойти эти возможности - т.е. легко написать винды например в стиле говнокода без всякой декомпозиции.
Соответственно, если супер-мозг будет даже в миллиарды разы круче, чем человек, то без внятных правил композиции/декомпозиции, он сможет решать задачи всего лишь раза в 3-10 больше.
Основная проблема не в самой аудитории, а в необходимости выяснения, что аудитория является разделяемым изменяемым состоянием. Даже в этом примере, таким разделяемым ресурсом может быть также преподаватель, что-нибудь типа журнала регистрации, сами студенты, гардероб, какой-нибудь проектор и т.д.
Само выяснение конфликта требует экспоненциальной вычислительной сложности. Если конфликт найден, то его уже можно разрешить за вычислительную сложность близкую к линейной.
Само выяснение конфликта требует экспоненциальной вычислительной сложности. Если конфликт найден, то его уже можно разрешить за вычислительную сложность близкую к линейной.
Пока что речь идет о скромных способностях человека - типа он может комбинировать 6 -7 сущностейречь о том, что супермозг, обладая в миллиарды раз большей вычислительной мощностью, сможет комбинировать лишь 10(может 15) сущностей вместо 6-7, потому что все алгоритмы по комбинированию(произвольному) растут экспоненциально от размера.
Это субъективная вещь, обусловленная ограничениями человеческого восприятия - человек не в состоянии логически отследить последствия изменения слишком большого числа переменныхА почему дело именно в изменяемых переменных? Если переменных/сущностей много >7 человек не может их комбинировать вне зависимости меняются они или нет.
...
Пока что речь идет о скромных способностях человека - типа он может комбинировать 6 -7 сущностей + что-то (буквально мегабайт не больше) помнить о системе.
А почему дело именно в изменяемых переменных?потому что совместное использование изменяемого состояния приводит к конфликтам. Совместное использование неизменяемого состояния к конфликтам не приводит.
Соответственно, при объединении двух кодов в первом случае такие конфликты надо выделять и устранять, а во втором случае выделять не надо.
Другими словами: при наличии изменяемого состояния два кода надо комбинировать строго определенным образом (необходимо из всех возможных комбинаций выбрать одну из правильных а без изменяемого состояния комбинировать можно произвольным способом (из всех комбинаций достаточно выбрать первую попавшуюся). Первое - требует экспоненциальных затрат, второе - линейные затраты (или вообще констатные)
Перевожу пример даркгрея на понятный русский язык. Если ты проводишь пару по матану, занимая для этой цели аудиторию, и Вася проводит пару по терверу, занимая для этой цели аудиторию, то для того чтобы вы могли обучить вмкшников математике, вам нужен внешний компонент, который будет рулить расписанием по аудиториям, иначе будут конфликты. Если б можно было просто отдавать на вход курс произвольных студентов, а получать на выходе курс обученных матану студентов, всё было бы значительно проще.Конфликты из-за аудитории? Как это применимо к даркгреивскому примеру с A и B кодами? Не берем во внимание проблемы какого-нибудь JS, пусть это будет Java или C#. Код A инстанцирует свои объекты, код B свои. Где тут "аудитория", из-за которой может быть конфликт?
Код A инстанцирует свои объекты, код B свои.тут ты потребовал другие неявные ограничения - два кода не имеют разделяемых переменных, и два кода при объединении не передают друг другу свои объекты.
Само выяснение конфликта требует экспоненциальной вычислительной сложности. Если конфликт найден, то его уже можно разрешить за вычислительную сложность близкую к линейной.В данном случае выяснение конфликта не требует вообще ничего, потому что конфликт обнаружится в момент так сказать возникновения конфликта.
В данном случае выяснение конфликта не требует вообще ничего, потому что конфликт обнаружится в момент так сказать возникновения конфликта.во-первых, подход "кто первый встал, того и тапки" с точки зрения конечного заказчика не работает, потому что он столкнется с тем, что одна из групп студентов осталась необученной, либо заблокировалась на неопределенный срок, а учителю придется все равно деньги выплатить за "ложный вызов".
во-вторых, это ты про ситуацию, когда уже кто-то при проектировании подумал о том, что такой конфликт возможен, и вставил код по защите от такого конфликта. и обязал всех остальных только такой вариант доступа к ресурсу использовать. Что приводит к задаче аналогичной предыдущей: для двух кодов необходимо убедиться, что они используют один и тот же алгоритм для доступа к одному и тому же ресурсу.
Конфликты из-за аудитории? Как это применимо к даркгреивскому примеру с A и B кодами? Не берем во внимание проблемы какого-нибудь JS, пусть это будет Java или C#. Код A инстанцирует свои объекты, код B свои. Где тут "аудитория", из-за которой может быть конфликт?Давай предположим, что эти коды пишут что-то на stdout или, ещё хуже, читают что-то с stdin. Продолжать?
Давай предположим, что эти коды пишут что-то на stdout или, ещё хуже, читают что-то с stdin. Продолжать?Внешние ресурсы это внешние ресурсы.
В первую же очередь интересуют обычные переменные (филды и т.д.). Чем плохо, когда они изменяемые?
В первую же очередь интересуют обычные переменные (филды и т.д.).для всего остального кода эти филды такие же внешние ресурсы, как и stdout/stdin.
во-первых, подход "кто первый встал, того и тапки" с точки зрения конечного заказчика не работает, потому что он столкнется с тем, что одна из групп студентов осталась необученной, либо заблокировалась на неопределенный срок, а учителю придется все равно деньги выплатить за "ложный вызов".Это только в первые несколько недель, дальше ситуация устаканится, все разберутся, когда надо примерно приходить. Вообще, в практике програмирования примерно так и происходит - сначала говнокодят, потом смотрят работает или нет.
Вообще, в практике програмирования примерно так и происходит - сначала говнокодят, потом смотрят работает или нет.такой код взлетает только на пустом рынке (или когда код впаривается заказчику нерыночными методами). При таком подходе код продолжает глючит у пользователей, что стимулирует их искать другого поставщика.
для всего остального кода эти филды такие же внешние ресурсы, как и stdout/stdin.что общего между филдами и stdout/stdin? Кроме того что они меняются, т.е. в них можно писать и читать.
Различия есть. Например, пользователь может взаимодействовать с stdout/stdin, а с филдами нет.
Короче, аналогия не понятна.
Различия есть. Например, пользователь может взаимодействовать с stdout/stdin, а с филдами нет.нет никакого различия.
с точки зрения отдельного куска кода: в обоих случаях есть разделяемое изменяемое состояние - которое меняет как этот кусок кода, так и кто-то другой. И для кода не важно является ли этот кто-то другой - пользователем, или другим кодом. Проблемы возникают одни и те же.
Проблемы возникают одни и те же.вот в том то и вопрос какие?
вот в том то и вопрос какие?после очередного изменения код перестает работать у одного из пользователей.
после очередного изменения код перестает работать у одного из пользователей.как будто такого не бывает без изменяемого состояния.
как будто такого не бывает без изменяемого состояния.такого не бывает, если в коде нет изменяемого состояния и изменение кода ведется только методом добавления нового кода.
вот в том то и вопрос какие?Я гимназиев не кончал, но с моей точки зрения изменяемые разделяемые переменные фактически переходят в разряд входных данных. То есть, фактически ты получаешь функцию от n+m переменных, у тебя увеличивается число валидируемых и обрабатываемых элементов, проверять код становится сложнее.
фактически ты получаешь функцию от n+m переменных2 и
Уже давно пора перейти к примерам кода.
Приведите простой пример кода A и B вот для этого:
если есть код А, решающий задачу P1 и код B, решающий задачу P2, то нет гарантии (сложно предсказать что код A+B сможет решить задачу P1+P2
static void A
{
System.Threading.Thread.CurrentThread.CurrentCulture = System.Globalization.CultureInfo.GetCultureInfo("en");
Console.WriteLine(DateTime.Now);
}
static void B(string v)
{
Console.WriteLine("{0:f2}", double.Parse(v;
}
public static void Main(string[] args)
{
if (args.FirstOrDefault == "A")
{
A;
return;
}
if (args.FirstOrDefault == "B")
{
B("1,2");
return;
}
if (args.FirstOrDefault == "A+B")
{
A;
B("1,2");
return;
}
}
вывод
> Program.exe A
3/10/2014 7:03:38 PM
> Program.exe B
1,20
> Program.exe A+B
3/10/2014 7:03:38 PM
12.00
какая задача не решена?
B. должна была вывести 1,20 (или хотя бы 1.20 а вывела 12.00
да ладно, у меня стоит английская локаль в системе, в обоих случаях результат одинаковый
в задаче P2 сказано распарсить и напечатать число согласно текущей локали. Эта задача решена.
у меня стоит английская локаль в системе, в обоих случаях результат одинаковыйвыполни тогда следующий код. получишь для A+B исключение
static void A
{
System.Threading.Thread.CurrentThread.CurrentCulture = System.Globalization.CultureInfo.GetCultureInfo("ru");
Console.WriteLine(DateTime.Now);
}
static void B(string v)
{
Console.WriteLine("{0:f2}", double.Parse(v;
}
public static void Main(string[] args)
{
if (args.FirstOrDefault == "A")
{
A;
return;
}
if (args.FirstOrDefault == "B")
{
B("1.2");
return;
}
if (args.FirstOrDefault == "A+B")
{
A;
B("1.2");
return;
}
}
в задаче P2 сказано распарсить и напечатать число согласно текущей локали"текущей" для чего? и в какой промежуток времени?
"текущей" для чего? и в какой промежуток времени?ты же пример приводишь, ты и пиши формулировки. В первоначальном утверждении у тебя есть P1, P2, A, B, вот и распиши эти обозначения для конкретного примера.
Неявность.А immutable замыкание это явно?
я не знаю что такое immutable замыкание. Это то, исходный код которого не меняется?
Осмысленных программ без стейта быть не может. И вообще любая программа исполняется на компе, который стейтфул, и абстракции текут, а программы на листочках интересны только в качестве мысленного эксперимента.
Если стейт указан явно, то программист пытается его минизировать, документировать, и этот стейт отслеживать проще. Плюс выделения явной сущности позволяет наработать best practices по работе с ней.
А вообще инструмент не важен - важно восприятие. Соблюдая определённые правила программирования, можно и на ассемблере разрабатывать в ООП стиле, только это будет ещё более многословно, чем на яве.
Осмысленных программ без стейта быть не может. И вообще любая программа исполняется на компе, который стейтфул, и абстракции текут, а программы на листочках интересны только в качестве мысленного эксперимента.
Если стейт указан явно, то программист пытается его минизировать, документировать, и этот стейт отслеживать проще. Плюс выделения явной сущности позволяет наработать best practices по работе с ней.
А вообще инструмент не важен - важно восприятие. Соблюдая определённые правила программирования, можно и на ассемблере разрабатывать в ООП стиле, только это будет ещё более многословно, чем на яве.
я не знаю что такое immutable замыкание. Это то, исходный код которого не меняется?Это когда значения свободных переменных не меняются.
я не знаю что такое immutable замыкание. Это то, исходный код которого не меняется?Вероятно, не изменяющее захваченные объекты, не?
А, ну тогда окей. Это же тогда просто объект-функция. А функции во многих языках не менее полноправные жильцы чем целые числа. Это если учесть, что захваченные объекты не были изменены где-то ещё, иначе получается, что где-то произошло неявное изменение состояния.
Это если учесть, что захваченные объекты не были изменены где-то ещё, иначе получается, что где-то произошло неявное изменение состояния.Для верности можно их по значению хватать.
А функции во многих языках не менее полноправные жильцы чем целые числа.Изменяемое состояние тоже во многих языках встроено.
Что значит твое: "Неявность"?
Что значит твое: "Неявность"?Элементарные операции (прописанные в языке) все известны программисту, он знает их эффект. Но если он хочет использовать композицию и объединять код, написанный сейчас, с кодом, написанным год назад другим человеком, он должен чётко представлять, что именно более сложная структура (например функция) делает. Если у ней нет побочных эффектов (включая в них отжирание всей свободной оперативки то сделать это просто. А иначе - надо держать внутреннее устройство функций в уме. И это сильно уменьшает эффективность программиста. Обычно для борьбы с этой задачей программист разрабатывает для себя некоторые классификаторы, которые мысленно навешивает но тот или иной код. В корне дерева лежит разделение "чистый" - "с побочными эффектами", а дальше уже следует классификация этих эффектов по замороченности и области возникновения.
Теперь подробнее о неявности. Она бывает двух типов.
Во-первых, неявность локализации - какая именно часть общего состояния затрагивается кодом. Знать это нужно для того, чтобы без смущения комбинировать код работающий с разными аспектами состояния.
Во-вторых, неявность роли - каким образом с состоянием работает данная функция? Например, является ли она поставщиком или потребителем в вариации классического producer-consumer. Потому что роль оказывает разные ограничения на способности комбинирования.
Поэтому замечательным был бы тот язык, которые позволяет навешивать классификацию сайд эффектов на свои конструкции и энфорсить их на стадии компиляции, плюс реализовывает несколько базовых механизмов обращения с общим состоянием, от которых мог бы отталкиваться программист.
Поэтому замечательным был бы тот язык, которые позволяет навешивать классификацию сайд эффектов на свои конструкции и энфорсить их на стадии компиляцииЯ слышал от разных явамакак, что даже "const из C/C++ нинужын!111", так что боюсь, что нет пути. Ты будешь больше метки расставлять, чем код писать.
Поэтому замечательным был бы тот язык, которые позволяет навешивать классификацию сайд эффектов на свои конструкции и энфорсить их на стадии компиляцииЭто, вроде, можно выводить автоматически: чистый код пользуется только чистым кодом (зашкварившийся делает всех зашкварившимися
). Зависимости по данным нужны для реордеринга, по крайней мере, так что современные компиляторы должны уметь в них, до известной степени.Это, вроде, можно выводить автоматически: чистый код пользуется только чистым кодом (зашкварившийся делает всех зашкварившимисяБольшая часть кода будет "зашкварившейся". Так что разбираться в сортах говна всё-таки нужно.
Большая часть кода будет "зашкварившейся".Кода на хаскеле не существует, что ли?
А ты посмотри сколько его там есть без использования всяких монад состояний и монад массивов.
И что? Это как-то чему-то противоречит?
Это показывает, что состояние расползается как грязь. Впрочем, в хаскеле оно как раз явным образом помечено.
Э-э, извини, я не понял, как наличие монады "состояния" противоречит чистоте хаскеля.
Я конечно только краем уха слыхал про такое, но мне кажется что const из c/c++ не нужны потому что в традиции джавы не западло написать 100500 избыточного кода который их примерно эмулирует.
"const из C/C++ нинужын!111"
Типа, будет иммутабельный класс Something только с геттерами, и будет класс SomethingBuilder мутабельный и умеющий возвращать Something.
А статически знать что там функция (сорри, метод) принимает, Something или SomethingBuilder - всё равно полезно.
Я чаще видел, что всякие мутабельные объекты заворачивают в какие-нибудь обёртки, которые кидают эксепшены на вызовы изменяющих состояние методов.
В любом случае вывод один: нужно больше фабрик и XML.
В любом случае вывод один: нужно больше фабрик и XML.
Э-э, извини, я не понял, как наличие монады "состояния" противоречит чистоте хаскеля.Не наличие, а массовое использование в любом неакадемическом коде. Потому как без этого хаскель - сильный тормоз. Так что метод чистого хаскеля - не панацея. Слишком большой ценой он достигается.
Нет, а что такого нечистого ты усматриваешь в монадах, извини еще раз?
Это чистый, но "зашкварившийся" код.
Осмысленных программ без стейта быть не может. И вообще любая программа исполняется на компе, который стейтфул, и абстракции текут, а программы на листочках интересны только в качестве мысленного эксперимента.Давай ближе к жизни.
Если стейт указан явно, то программист пытается его минизировать, документировать, и этот стейт отслеживать проще. Плюс выделения явной сущности позволяет наработать best practices по работе с ней.
Случай 1. Серверная часть веб приложения. Веб сервер без состояния. Пришел реквест, что-то поделали, слазили/записали в базу. Зачем тут использовать объекты с изменяемым состоянием? Однако многие фреймворки делают это, используя изменяемое состояние. Это и ORM и другие части фрейворков.
Случай 2. Rich клиент. Есть состояние в UI-элементах. Это нам дано с выше, тут мы не выбираем. Но люди также начинают городить свои объекты с изменяемым состоянием. Называют они их Model, View Model, Presenter т.п. Зачем? И чем это плохо?
Зачем тут использовать объекты с изменяемым состоянием?база сама по себе объект с изменяемым состоянием. Соответственно, и инструменты упрощающие и ускоряющие доступ к БД, скорее всего, будут такими же.
Но люди также начинают городить свои объекты с изменяемым состоянием. Называют они их Model, View Model, Presenter т.п. Зачем? И чем это плохо?то, что Model имеет изменяемое состояние - это тоже дано нам свыше. Данное состояние можно представить в виде серии неизменяемых состояний - это иногда упрощает код, но ухудшает производительность.
И чем это плохо?Трудности с комбинированием нескольких презентеров для одного контрола
база сама по себе объект с изменяемым состоянием.Спасибо, КО. Но я про объекты, которые обрабатывают реквест.
Соответственно, и инструменты упрощающие и ускоряющие доступ к БД, скорее всего, будут такими же.Это почему?
Это из серии наш мир с изменяемым состоянием, поэтому и софт должен быть таким.
то, что Model имеет изменяемое состояние - это тоже дано нам свыше.
У меня "с выше" это не то, что вы подумали. Это не Бог, о котором вы подумали. Это всего лишь та реальность, в которой сейчас пишется UI.
Данное состояние можно представить в виде серии неизменяемых состояний - это иногда упрощает код, но ухудшает производительность.
Содержание этого поста в том, что нерадивый программист косячит? Он косячит при любом подходе. Спасибо, КО.
Он косячит при любом подходе.Косяки зависят от сложности: чем выше сложность, тем больше косяков. Сложность измеряется в кол-ве учитываемых для выполнения задачи понятий и взаимосвязей между ними.
От сложности также зависит и сама возможность решения задачи. При превышении сложности выше определенного порога программист становится не в состоянии решить задачу вообще.
Это почему?растет сложность.
во-первых, требуется вводить метафору по преобразованию изменяемого состояния в серию неизменяемых (и обратно а также необходимо разобраться какие изменяемые состояния можно выкинуть без потери смысла, а какие требуют замены на серию неизменяемых.
во-вторых, при работе с кодом необходимо будет одновременно отслеживать, что происходить с данными, как в неизменяемом состояния, так и в изменяемом в БД (это следствие того, что все метафоры протекают).
Что касается веба - он же сетевое приложение и обречён на изменяемое состояние. Как по-твоему там handshake устраивать? Перепосылать недополученные данные и т.п. Если всё эти задачи выполняет сервисная часть (фреймворк а ты об этом не знаешь, то это не значит, что их не существует.
во-вторых, при работе с кодом необходимо будет одновременно отслеживать, что происходить с данными, как в неизменяемом состояния, так и в изменяемом в БД (это следствие того, что все метафоры протекают).Но иногда введение этих метафор оправдано. Особенно в ситуации когда на одного программиста, который их реализует, приходится десять тысяч, которые их используют. И использование метафор всё равно дешевле и анализ их подтёков всё равно дешевле чем полная реализация каждый раз. Вспомни как сильно упростилось программирования после введения транзакций.
Вспомни как сильно упростилось программирования после введения транзакций.получается как-то так..
метафоры бывают двух типов.
Первый вид метафоры - упрощает решение задач, но увеличивает сложность порога входа. Обычно такая метафора сопровождается увеличением кол-ва используемых понятий.
Второй вид метафор - уменьшает порог входа, но усложняет решение проблем в "темных углах" ("местах протечки"). Обычно такие метафоры уменьшают кол-во используемых понятий.
соответственно, ввод метафор оправдан, если они действительно позволяют решать более широкий круг задач за те же ресурсы, или позволяют привлечь более широкую аудиторию.
во-первых, требуется вводить метафору по преобразованию изменяемого состояния в серию неизменяемых (и обратно а также необходимо разобраться какие изменяемые состояния можно выкинуть без потери смысла, а какие требуют замены на серию неизменяемых.Не понятно, к чему это в этой ветке. Пришел реквест, сгенерировали для базы SELECT/INSERT/UPDATE/DELETE выражения, написали респонс. Зачем тут метафоры с изменяемым состоянием?
во-вторых, при работе с кодом необходимо будет одновременно отслеживать, что происходить с данными, как в неизменяемом состояния, так и в изменяемом в БД (это следствие того, что все метафоры протекают).
соответственно, ввод метафор оправдан, если они действительно позволяют решать более широкий круг задач за те же ресурсы, или позволяют привлечь более широкую аудиторию.В жопу. Кодеры должен брать качеством, а не количеством.
А так, конечно, понятно. Как не прекрасен хаскель, а содержит кучу новых метафор, их же ещё понимать надо. Давайте лучше на php кодить, он любые ошибки "прощает". Программисту. Правда эти программы почему-то потом не нравятся пользователям.
Что касается веба - он же сетевое приложение и обречён на изменяемое состояние. Как по-твоему там handshake устраивать? Перепосылать недополученные данные и т.п. Если всё эти задачи выполняет сервисная часть (фреймворк а ты об этом не знаешь, то это не значит, что их не существует.Речь идет о прикладной части, которая реализует конкретную бизнес логику. Пусть простой случай синхронный код.
Зачем тут метафоры с изменяемым состоянием?производительность.
Если пользователей много, то почти сразу захочется часть данных брать из внутреннего кэша, а не лезть каждый раз в базу. Кэш же и сам по себе имеет изменяемое состояние (данных сначала не было, а потом появились так еще и сами данные могут меняться в процессе работы, что потребует аккуратной синхронизации состояния кэша с БД.
производительность.На обычном железе база держит около 10^4 обычных запросов в секунду. Пусть на каждого пользователя 10-20 запросов в базу. Не многие сайты могут похвастаться посещаемостью в несколько сотен запросов в секунду.
Если пользователей много, то почти сразу захочется часть данных брать из внутреннего кэша, а не лезть каждый раз в базу. Кэш же и сам по себе имеет изменяемое состояние (данных сначала не было, а потом появились так еще и сами данные могут меняться в процессе работы, что потребует аккуратной синхронизации состояния кэша с БД.
обречён на изменяемое состояниеПравда, что ли?
обычных запросовиногда приходится использовать более тяжелые запросы, которые уже при количестве порядка сотни сильно затормаживают бд. В этом случае без кеширования никак.
иногда приходится использовать более тяжелые запросы, которые уже при количестве порядка сотни сильно затормаживают бд. В этом случае без кеширования никак.Предвычесленные данные можно держать в той же реляционке (если умещаются и доставать их обычными запросами. Но это отдельная большая тема, и мы сильно отклоняемся от первоначальной темы. Если речь об ORM, то вроде все соглашаются, что они снижают производительность, а тут это прозвучало, как аргумент в их пользу. Короче, остается не понятным, что хорошего дает наличие изменяемого состояния в ORM-ах?
На обычном железе база держит около 10^4 обычных запросов в секунду.in-memory ?
in-memory ?обычный MS SQL Server
Ну данные явно не на вращающихся дисках?
Ну данные явно не на вращающихся дисках?На вращающихся. Данные, естественно, СУБД кэширует в памяти.
ну то есть working set влезает в память, а обновления не обязательно писать на диск сразу? тогда конечно
ну то есть working set влезает в память, а обновления не обязательно писать на диск сразу? тогда конечнопод "обычными" можно понимать небольшой процент запросов на обновления
даже если 1 из 10 обновление и нужно писать их на диск, то 10^4 не получится
даже если 1 из 10 обновление и нужно писать их на диск, то 10^4 не получитсяесли 1 из 30, то уже получится
У нас один из запросов вызывает нехилый расчет, в который входит куча dml-ок (порядка 20-30шт некоторое количество селектов и rollback в конце. Мы храним результат в сессии и обновляем раз в N минут, всё равно приходится запрос выполнять на отдельном сервере (более мощном, нежели основной при чем тот держит только порядка сотни одновременных запросов. Закешировать в бд это дело никак не получается, т.к. результат расчета может зависеть от кучи параметров, которые в любой момент могут поменяться, а упрощать расчет заказчик не хочет. Подозреваю, что подобные проблемы не только у нас встречаются.
Закешировать в бд это дело никак не получаетсяДля размышления — в ASP.NET (на других платформах, думаю, тоже) в конфиге можно указать, чтобы сессия сохранялась в базе.
в состоянии измененного сознания лучше не кодить 
Оставить комментарий
6yrop
Если не принимать во внимание всякие параллелизмы: многопоточность, горизонтальное масштабирование и т.п. Чем плохо изменяемое состояние?