Re[112]: Immutable object
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 05.01.12 15:20
Оценка:
S> ООП не подразумевает никакого "абсолютного наблюдателя".

согласен. но абсолютный наблюдатель может появиться (а может и не появиться), когда делаются те или иные утверждения о конкретной системе.

возьмем следующий код:
void main()
{
  var x = new X();
  x.Message();
  
  var y = new Y();
  y.Message();
}

class X
{  
  public void Message(){}
}
class Y
{
  Y1 y1 = new Y1();
  public void Message(){y1.Message();}
}
class Y1
{
  public void Message(){}
}




с точки зрения функции main(относительного наблюдателя) поведение объектов X и Y полностью одинаковое: посылается сообщение Message и ничего не происходит. и если для функции main разрешен лишь публичный интерфейс объектов X и Y, то у нее вообще нет способа узнать, что они отличаются
и лишь с позиции абсолютного наблюдателя мы знаем, что поведение объекта X отличается от поведение объекта Y (объект Y дополнительно посылает сообщение объекту Y1)

S> Всё, что удовлетворяет определениям — может рассматриваться как объект. Мы же говорим про математические основы ООП, а не про конкретную реализацию.


значит ты согласен с тем, что любую программу (множество объектов Os) можно представить как два объекта: объект Oi (где Oi из множества Os) и объект Oiw (весь остальной мир: все объекты из множества Os, кроме объекта Oi)?
Re[115]: Immutable object
От: Sinclair Россия https://github.com/evilguest/
Дата: 05.01.12 16:51
Оценка:
Здравствуйте, DarkGray, Вы писали:

DG>>>согласен ли ты с более сильной формулировкой?:

DG>>>выводы об объекте должны делаться только на основе его интерфейса (и не должны рассматриваться учитываться детали реализации)
S>>Нет.
S>>1. Не определено понятие "интерфейс"
DG>набор сообщений допустимый для использования в данном месте использования объекта
Экий вы шустрый. Вы сейчас пытаетесь ввести понятие классификации. Оно а) лишнее и б) его введение — дорогая штука (в объёме матаппарата, который нужно корректно построить). Десятком слов тут не обойдёшься. В частности, нужно определить понятие "допустимого сообщения" и понятие "место использования объекта".

S>>2. Не определено понятие "выводы"

DG>ок. пусть будет для начала один вывод: является или не является поведение двух объектов одинаковым
Ну, в таком случае я вижу некоторую тавтологию. В том смысле, что вы предлагаете судить о поведении объектов по их поведению, т.к. интерфейс в вашем определении сведётся (хоть и не сразу) к поведению объекта.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[113]: Immutable object
От: Sinclair Россия https://github.com/evilguest/
Дата: 05.01.12 16:59
Оценка:
Здравствуйте, DarkGray, Вы писали:
DG>согласен. но абсолютный наблюдатель может появиться (а может и не появиться), когда делаются те или иные утверждения о конкретной системе.
Абсолютного наблюдателя можно ввести искусственно в некоторую модель, и построить на основе этой модели конкретную систему. Но это совершенно необязательно.

DG>с точки зрения функции main(относительного наблюдателя) поведение объектов X и Y полностью одинаковое: посылается сообщение Message и ничего не происходит. и если для функции main разрешен лишь публичный интерфейс объектов X и Y, то у нее вообще нет способа узнать, что они отличаются

DG>и лишь с позиции абсолютного наблюдателя мы знаем, что поведение объекта X отличается от поведение объекта Y (объект Y дополнительно посылает сообщение объекту Y1)
Безо всякого абсолютного наблюдателя мы знаем, что поведение объекта X отличается от поведения объекта Y — достаточно посмотреть на него с точки зрения объекта Y1, который тоже относительный наблюдатель. И вот слово "невозможно" в определении инкапсуляции означает "независимо от того, с позиции какого наблюдателя мы ведём наблюдение".

S>> Всё, что удовлетворяет определениям — может рассматриваться как объект. Мы же говорим про математические основы ООП, а не про конкретную реализацию.

DG>значит ты согласен с тем, что любую программу (множество объектов Os) можно представить как два объекта: объект Oi (где Oi из множества Os) и объект Oiw (весь остальной мир: все объекты из множества Os, кроме объекта Oi)?
Тут есть некоторая сложность: если объект Оi "осведомлён" о наличии объектов Ok, Ol, Om, On, то склеить их все в один, не нарушив целостность модели, нельзя.
Благодаря идентичности, объект Oi прекрасно отличает ссылки на разные объекты от ссылок на один и тот же объект.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[74]: Immutable object
От: samius Япония http://sams-tricks.blogspot.com
Дата: 05.01.12 18:01
Оценка: 62 (1)
Здравствуйте, Sinclair, Вы писали:

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


V>>есть только одна эта задача на своем уровне, которая понятия не имеет о вызовах других printf(). И есть некий низлежащий слой ОС. И эта задача вполне может быть выполнена без побочных эффектов на своем уровне, передавая данные "куда-то дальше"...

S>Нет, она не может быть выполнена без побочных эффектов. Она целиком и полностью опирается на определённое поведение разделяемого состояния.
+1 (*)
V>>В чистых функциональных языках тоже ведь как-то ввод-вывод делают, просто разграничивают, что это делает "кто-то другой" через библиотеки.
S>А вы поинтересуйтесь, как же так в чистых функциональных языках делают ввод-вывод. Там ведь нет ничего сложного — просто вместо неявного состояния вычислителя, на котором работают императивные программы, вводится явное состояние аргумента. Грубо говоря, вместо void printf(...) у нас появляется
S>
S>Console printf(this Console in, String text);
S>

S>Сама printf здесь не имеет побочных эффектов — её можно вызывать на одном и том же аргументе сколько угодно раз, и результат всегда будет одинаковым.
Если она не имеет побочных эффектов, значит в консоли ничего не должно измениться. Вывод в консоль есть побочный эффект. см (*). Даже если значение Console, возвращаемое printf, полностью инкапсулирует "состояние консоли", все равно где-то должна остаться информация о том что нынче актуально состояние консоли, описанное именно в последнем экземпляре. И обновление этого знания будет являться побочным эффектом.

S>Чтобы задать порядок, надо явно писать

S>
S>console.printf("Hello").printf("World")
S>

Да, Console printf(this Console, String) — это способ упорядочить выполнение функций с побочным эффектом, но не избавиться от побочнго эффекта.

Побочный эффект можно отложить, что и делается в хаскеле. Следующая функция printf не содержит побочных эффектов. Побочные эффекты будет содержать результирующий Action
Action printf(String str)
{
    return () => { Console.WriteLine(str); };
}

В сочетании с необходимостью упорядочивать побочные эффекты мы как раз и получаем аналог хаскелевского вывода
class World {} // весьма топорно, но пойдет для примера.
Func<World, World> printf(String str)
{
    return world => { Console.WriteLine(str); return world; };
}
// или чуть ближе к putChar:: Char -> IO()
class Unit {};
Func<World, Tuple<Unit, World>> printf(String str)
{
    return world => { Console.WriteLine(str); return Tuple.Create(new Unit(), world); };
}
Re[114]: Immutable object
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 05.01.12 18:05
Оценка:
DG>>с точки зрения функции main(относительного наблюдателя) поведение объектов X и Y полностью одинаковое: посылается сообщение Message и ничего не происходит. и если для функции main разрешен лишь публичный интерфейс объектов X и Y, то у нее вообще нет способа узнать, что они отличаются
DG>>и лишь с позиции абсолютного наблюдателя мы знаем, что поведение объекта X отличается от поведение объекта Y (объект Y дополнительно посылает сообщение объекту Y1)

S>Безо всякого абсолютного наблюдателя мы знаем, что поведение объекта X отличается от поведения объекта Y — достаточно посмотреть на него с точки зрения объекта Y1, который тоже относительный наблюдатель.


во-первых: это будет точка зрения наблюдателя Y1, которая имеет слабое отношение к наблюдателю main
во-вторых: Y1 — может быть деталью реализации объекта Y и тогда ты не имеешь его брать в качестве одного из наблюдателей за поведением объекта Y
можно даже это явно зафиксировать сделав Y1 приватным
class Y
{
  Y1 y1 = new Y1();
  public void Message(){y1.Message();}

  class Y1
  {
    public void Message(){}
  }

}




S> И вот слово "невозможно" в определении инкапсуляции означает "независимо от того, с позиции какого наблюдателя мы ведём наблюдение".


ок. возьмем следующий код (модифицировав объект X и обозначив как Xr)
void main()
{
  var x = new Xr();
  x.Message();
  
  var y = new Y();
  y.Message();
}

class Xr
{  
  Y1 y1 = new Y1();
  public void Message()
  {
    if (new Random().Next() < 0.8)
      y1.Message();
  }
}
class Y
{
  Y1 y1 = new Y1();
  public void Message(){y1.Message();}
}
class Y1
{
  public void Message(){}
}


в данном случае, и с позиции наблюдателя main и с позиции наблюдателя Y1 поведение одно и тоже:
для main Xr и Y ничего не делают,
а для Y1 объекты Xr и Y иногда присылают сообщение.
и только с позиции абсолютного наблюдателя (либо из деталей реализации) мы понимаем, что поведение Xr и поведение Y различно.

S> поведение объекта X отличается от поведения объекта Y — достаточно посмотреть на него с точки зрения объекта Y1, который тоже относительный наблюдатель


здесь как минимум используется неявное требование, что утверждение main об объектах X и Y (один это объект, или два разных) должно быть тем же самым, что и мнение Y1.
или другими словами есть два подхода:
утверждения об объектах X и Y должны быть непротиворечивыми с точки зрения каждого наблюдателя
утверждения об объектах X и Y должны быть непротиворечивыми с точки зрения совокупности всех утверждений наблюдателей
или более формально:
в первом случае — непротиворечивость для всех наблюдателей(объектов) вводится как: непротиворечивость утверждений для всех наблюдателей(объектов) := and(непротиворечивость утверждений для каждого наблюдателя(объекта))
во втором случае — непротиворечивость для всех наблюдателей(объектов) вводится как: непротиворечивость утверждений для всех наблюдателей(объектов) := непротиворечивость(объединение утверждений для каждого объекта(наблюдателя))
первый подход для краткости называют относительным (непротиворечивость сохраняется лишь относительно одно наблюдателя), второй подход — абсолютным (непротиворечивость сохраняется для абсолютного наблюдателя)


S>>> Всё, что удовлетворяет определениям — может рассматриваться как объект. Мы же говорим про математические основы ООП, а не про конкретную реализацию.

DG>>значит ты согласен с тем, что любую программу (множество объектов Os) можно представить как два объекта: объект Oi (где Oi из множества Os) и объект Oiw (весь остальной мир: все объекты из множества Os, кроме объекта Oi)?
S>Тут есть некоторая сложность: если объект Оi "осведомлён" о наличии объектов Ok, Ol, Om, On, то склеить их все в один, не нарушив целостность модели, нельзя.
S>Благодаря идентичности, объект Oi прекрасно отличает ссылки на разные объекты от ссылок на один и тот же объект.

исходную программу (множество объектов Os) назовем построение 0
построение с множеством объектов Oi и объектом Oiw — назовем построение 1.

в построении 1:
объекты Oj (j != i) считаются ссылками на один большой объект Oiw (и соответственно, идентичность объектов в построении 0 переходит в идентичность ссылок в построении 1)
сообщения от Oi к Oj в построении 1 считаются как сообщения от Oi к Oiw и к аргументам еще добавляется Oj
сообщения от Oj к Oi в построении 1 считаются как сообщения от Oiw к Oi, аргументы те же самые

S>Благодаря идентичности, объект Oi прекрасно отличает ссылки на разные объекты от ссылок на один и тот же объект.


и соответственно в построении 1 объект Oi различает лишь ссылки на объект Oiw, но не более.
Re[116]: Immutable object
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 05.01.12 18:37
Оценка:
S>>>1. Не определено понятие "интерфейс"
DG>>набор сообщений допустимый для использования в данном месте использования объекта
S>Экий вы шустрый. Вы сейчас пытаетесь ввести понятие классификации. Оно а) лишнее и б) его введение — дорогая штука (в объёме матаппарата, который нужно корректно построить). Десятком слов тут не обойдёшься. В частности, нужно определить понятие "допустимого сообщения" и понятие "место использования объекта".

классификация еще не требуется (либо стоит уточнить о классификации чего и по каким призникам идет речь).

возьмем декларацию вида
void F(IEnumerable x){...}

это есть конкретное место использования объектов, передаваемых в функцию F,(обозначим такие объекты как x) и при этом фиксируется (если не сказано что либо еще), что функция F имеет право использовать лишь сообщения, которые входят в интерфейс IEnumerable, а не все сообщения которые поддерживает объект x



S>>>2. Не определено понятие "выводы"

DG>>ок. пусть будет для начала один вывод: является или не является поведение двух объектов одинаковым
S>Ну, в таком случае я вижу некоторую тавтологию. В том смысле, что вы предлагаете судить о поведении объектов по их поведению, т.к. интерфейс в вашем определении сведётся (хоть и не сразу) к поведению объекта.

он сведется к наблюдаемому поведению.
и соответственно я предлагаю отличать поведение объекта вообще от наблюдаемого поведения объекта.
и зафиксировать, что для наблюдателя важно лишь наблюдаемое поведение объекта, а не всякое.
Re[115]: Immutable object
От: Sinclair Россия https://github.com/evilguest/
Дата: 05.01.12 20:17
Оценка:
Здравствуйте, DarkGray, Вы писали:

DG>во-первых: это будет точка зрения наблюдателя Y1, которая имеет слабое отношение к наблюдателю main

Помните об относительности — все наблюдатели равноправны.

DG>во-вторых: Y1 — может быть деталью реализации объекта Y и тогда ты не имеешь его брать в качестве одного из наблюдателей за поведением объекта Y

Если это — деталь реализации, то да. Но в примере Y1 всё же является внешним объектом, благодаря чему и появляется возможность различить

DG>можно даже это явно зафиксировать сделав Y1 приватным

Не поможет. Вы прячете ссылку, а не объект.

DG>ок. возьмем следующий код (модифицировав объект X и обозначив как Xr)


DG>в данном случае, и с позиции наблюдателя main и с позиции наблюдателя Y1 поведение одно и тоже:

DG>для main Xr и Y ничего не делают,
DG>а для Y1 объекты Xr и Y иногда присылают сообщение.
А как же new Random()? Ему Xr постоянно посылает сообщение Next()

DG>здесь как минимум используется неявное требование, что утверждение main об объектах X и Y (один это объект, или два разных) должно быть тем же самым, что и мнение Y1.

DG>или другими словами есть два подхода:
DG>утверждения об объектах X и Y должны быть непротиворечивыми с точки зрения каждого наблюдателя
DG>утверждения об объектах X и Y должны быть непротиворечивыми с точки зрения совокупности всех утверждений наблюдателей
Вы забегаете вперёд. В базовой модели ООП нет никакого глобального анализа поведения объектов (кроме, собственно, принципа причинности). Инкапсуляция не требует согласованности картины, наблюдаемой всеми возможными наблюдателями.

DG>или более формально:

DG>в первом случае — непротиворечивость для всех наблюдателей(объектов) вводится как: непротиворечивость утверждений для всех наблюдателей(объектов) := and(непротиворечивость утверждений для каждого наблюдателя(объекта))
DG>во втором случае — непротиворечивость для всех наблюдателей(объектов) вводится как: непротиворечивость утверждений для всех наблюдателей(объектов) := непротиворечивость(объединение утверждений для каждого объекта(наблюдателя))
DG>первый подход для краткости называют относительным (непротиворечивость сохраняется лишь относительно одно наблюдателя), второй подход — абсолютным (непротиворечивость сохраняется для абсолютного наблюдателя)
Ок, пусть так. В базовой модели не требуется наличие абсолютного наблюдателя.

S>>Благодаря идентичности, объект Oi прекрасно отличает ссылки на разные объекты от ссылок на один и тот же объект.


DG>исходную программу (множество объектов Os) назовем построение 0

DG>построение с множеством объектов Oi и объектом Oiw — назовем построение 1.
Непонятно, что такое множество объектов Oi.
DG>в построении 1:
DG> объекты Oj (j != i) считаются ссылками на один большой объект Oiw (и соответственно, идентичность объектов в построении 0 переходит в идентичность ссылок в построении 1)
То есть объекты Oj всё ещё существуют, но у них нет собственного состояния и поведения — они всего лишь транслируют сообщения некоторому другому объекту Oiw?
Это в принципе изоморфно предыдущему примеру с Xr и Y. C точки зрения объекта Oi ничего не поменяется; с точки зрения объектов Oj разница есть.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[117]: Immutable object
От: Sinclair Россия https://github.com/evilguest/
Дата: 05.01.12 20:22
Оценка:
Здравствуйте, DarkGray, Вы писали:
DG>классификация еще не требуется (либо стоит уточнить о классификации чего и по каким призникам идет речь).
Вы пытаетесь ввести концепцию интерфейса. Когда вы её разовьёте, получите концепцию типа ссылки. Но уже на первом этапе получается, что разные объекты удовлетворяют разным интерфейсам — вот вам и классификация.
DG>возьмем декларацию вида
DG>
DG>void F(IEnumerable x){...}
DG>

DG>это есть конкретное место использования объектов, передаваемых в функцию F,(обозначим такие объекты как x)
Вы уже ввели понятие функции и понятие интерфейса. Ни того ни другого в базовой модели ООП нет
DG> и при этом фиксируется (если не сказано что либо еще), что функция F имеет право использовать лишь сообщения, которые входят в интерфейс IEnumerable, а не все сообщения которые поддерживает объект x
И ввели понятия "сообщения, которые поддерживает объект х" и "сообщения, которые поддерживает интерфейс i"

DG>он сведется к наблюдаемому поведению.

DG>и соответственно я предлагаю отличать поведение объекта вообще от наблюдаемого поведения объекта.
А зачем? Зачем нам вообще нужно ненаблюдаемое поведение? Если его невозможно наблюдать, то в него можно только верить.
DG>и зафиксировать, что для наблюдателя важно лишь наблюдаемое поведение объекта, а не всякое.
Предлагаю зафиксировать, что ненаблюдаемым поведением можно вообще пренебречь.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[116]: Immutable object
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 05.01.12 21:32
Оценка:
DG>>во-вторых: Y1 — может быть деталью реализации объекта Y и тогда ты не имеешь его брать в качестве одного из наблюдателей за поведением объекта Y
S>Если это — деталь реализации, то да. Но в примере Y1 всё же является внешним объектом, благодаря чему и появляется возможность различить

могу сказать твоими же словами: определения "внешний объект" в базовой концепции ООП нет.
дай определение — что такое внешний объект. внешний по отношению к чему? и каким образом определяется — объект внешний или нет?



S>А как же new Random()? Ему Xr постоянно посылает сообщение Next()


во-первых: мне необходимо переписать код, создав псевдослучайность без использования внешних объектов, чтобы ты ответил на то, о чем я спрашиваю?
во-вторых: объект Random не умеет отличать кто именно ему послал сообщение (за него это делает внешняя среда). соответственно он как наблюдатель не знает — ему посылает сообщения только какой-то один объект из пары (X,Y), или оба, или вообще кто-то третий.

DG>>здесь как минимум используется неявное требование, что утверждение main об объектах X и Y (один это объект, или два разных) должно быть тем же самым, что и мнение Y1.

DG>>или другими словами есть два подхода:
DG>>утверждения об объектах X и Y должны быть непротиворечивыми с точки зрения каждого наблюдателя
DG>>утверждения об объектах X и Y должны быть непротиворечивыми с точки зрения совокупности всех утверждений наблюдателей
S>Вы забегаете вперёд. В базовой модели ООП нет никакого глобального анализа поведения объектов (кроме, собственно, принципа причинности). Инкапсуляция не требует согласованности картины, наблюдаемой всеми возможными наблюдателями.

тогда непонятно на основании чего ты для ответа на вопрос "является ли поведение объектов X и Y для функции main одинаковым?" используешь ответ на вопрос "является ли поведение объектов X и Y для всех объектов одинаковым"?

DG>>или более формально:

DG>>в первом случае — непротиворечивость для всех наблюдателей(объектов) вводится как: непротиворечивость утверждений для всех наблюдателей(объектов) := and(непротиворечивость утверждений для каждого наблюдателя(объекта))
DG>>во втором случае — непротиворечивость для всех наблюдателей(объектов) вводится как: непротиворечивость утверждений для всех наблюдателей(объектов) := непротиворечивость(объединение утверждений для каждого объекта(наблюдателя))
DG>>первый подход для краткости называют относительным (непротиворечивость сохраняется лишь относительно одно наблюдателя), второй подход — абсолютным (непротиворечивость сохраняется для абсолютного наблюдателя)
S>Ок, пусть так. В базовой модели не требуется наличие абсолютного наблюдателя.

S>Предлагаю зафиксировать, что ненаблюдаемым поведением можно вообще пренебречь.


исходя из этих двух утверждений ответь на вопрос:
поведение(оно же наблюдаемое поведение, т.к. ненаблюдаемым поведением пренебрегаем) объектов X и Y для функции main одинаковое или нет?
Re[116]: Immutable object
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 05.01.12 21:45
Оценка:
S>То есть объекты Oj всё ещё существуют, но у них нет собственного состояния и поведения — они всего лишь транслируют сообщения некоторому другому объекту Oiw?

вот этот вопрос фактически спрашивает "а как оно на самом деле?", или другими словами "а какое оно с точки зрения абсолютного наблюдателя?".

в относительной парадигме может быть лишь утверждение:
объект Oi исходит из модели, что у объектов Oj нет собственного состояния и поведения, и что они всего лишь транслируют сообщения некоторому другому объекту Oiw, и поведение, наблюдаемое объектом Oi, не создает противоречие с этой моделью.
Re[116]: Immutable object
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 05.01.12 22:35
Оценка:
DG>>набор сообщений допустимый для использования в данном месте использования объекта
S>Экий вы шустрый. Вы сейчас пытаетесь ввести понятие классификации. Оно а) лишнее и б) его введение — дорогая штука (в объёме матаппарата, который нужно корректно построить). Десятком слов тут не обойдёшься. В частности, нужно определить понятие "допустимого сообщения" и понятие "место использования объекта".

S> Но уже на первом этапе получается, что разные объекты удовлетворяют разным интерфейсам — вот вам и классификация.


ок. пусть будет классификация.
тогда остается вопрос — лишнее для чего?

вся возня с парадигмами программирования (в том числе и с ООП) делается для решения задачи: продвинуться дальше в достижении целей: (максимизация множества решаемых задач, максимальная производительность кода, максимальная скорость разработки, максимальное соответствие работы программы ожидаемому поведению, стоимость разработки, стоимость сопровождения). при этом максимизация происходит как в одной цели за счет других, так есть и общее продвижение.
общее продвижение, в частности, происходит при движении к цели: предсказуемость поведения программы без ее запуска.
и соответственно без классификации объектов невозможно продвинуться к данной цели (предсказуемость поведения программы без ее запуска).
Re[117]: Immutable object
От: Sinclair Россия https://github.com/evilguest/
Дата: 06.01.12 05:28
Оценка:
Здравствуйте, DarkGray, Вы писали:

DG>могу сказать твоими же словами: определения "внешний объект" в базовой концепции ООП нет.

DG>дай определение — что такое внешний объект. внешний по отношению к чему? и каким образом определяется — объект внешний или нет?
Все объекты внешние.
DG>во-первых: мне необходимо переписать код, создав псевдослучайность без использования внешних объектов, чтобы ты ответил на то, о чем я спрашиваю?
Да.
DG>во-вторых: объект Random не умеет отличать кто именно ему послал сообщение (за него это делает внешняя среда). соответственно он как наблюдатель не знает — ему
посылает сообщения только какой-то один объект из пары (X,Y), или оба, или вообще кто-то третий.
Да, вы правы — в базовой модели не требуется опознавать отправителя сообщения.

DG>тогда непонятно на основании чего ты для ответа на вопрос "является ли поведение объектов X и Y для функции main одинаковым?" используешь ответ на вопрос "является ли поведение объектов X и Y для всех объектов одинаковым"?

Потому что мне неинтересен вопрос поведения объектов для функции main.

S>>Предлагаю зафиксировать, что ненаблюдаемым поведением можно вообще пренебречь.


DG>исходя из этих двух утверждений ответь на вопрос:

DG>поведение(оно же наблюдаемое поведение, т.к. ненаблюдаемым поведением пренебрегаем) объектов X и Y для функции main одинаковое или нет?
В данном примере — да.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[117]: Immutable object
От: Sinclair Россия https://github.com/evilguest/
Дата: 06.01.12 05:30
Оценка:
Здравствуйте, DarkGray, Вы писали:

S>>То есть объекты Oj всё ещё существуют, но у них нет собственного состояния и поведения — они всего лишь транслируют сообщения некоторому другому объекту Oiw?


DG>вот этот вопрос фактически спрашивает "а как оно на самом деле?", или другими словами "а какое оно с точки зрения абсолютного наблюдателя?".

Конечно. Мы же с вами являемся "абсолютными наблюдателями" в этой воображаемой модели, поэтому я и проясняю у вас толкование непонятных мне моментов.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[117]: Immutable object
От: Sinclair Россия https://github.com/evilguest/
Дата: 06.01.12 05:32
Оценка:
Здравствуйте, DarkGray, Вы писали:

DG>ок. пусть будет классификация.

DG>тогда остается вопрос — лишнее для чего?
Для базовой модели ООП.
Модель с классами и интерфейсами значительно сложнее, и она опциональна. Скажем, в JavaScript ни классов, ни интерфейсов нет. В SmallTalk нет понятия "допустимое сообщение".
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[118]: Immutable object
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 06.01.12 12:31
Оценка:
DG>>вот этот вопрос фактически спрашивает "а как оно на самом деле?", или другими словами "а какое оно с точки зрения абсолютного наблюдателя?".
S>Конечно. Мы же с вами являемся "абсолютными наблюдателями" в этой воображаемой модели, поэтому я и проясняю у вас толкование непонятных мне моментов.

если последовательно используется относительная парадигма вопрос должен быть другой:
с позиции абсолютного наблюдателя верно ли, что поведение, наблюдаемое объектом Oi, не создает противоречие с его моделью, что у объектов Oj нет собственного состояния и поведения, и что они всего лишь транслируют сообщения некоторому другому объекту Oiw
?
Re[118]: Immutable object
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 06.01.12 13:17
Оценка:
DG>>ок. пусть будет классификация.
DG>>тогда остается вопрос — лишнее для чего?
S>Для базовой модели ООП.
S>Модель с классами и интерфейсами значительно сложнее, и она опциональна. Скажем, в JavaScript ни классов, ни интерфейсов нет. В SmallTalk нет понятия "допустимое сообщение".

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

S>Модель с классами и интерфейсами значительно сложнее, и она опциональна. Скажем, в JavaScript ни классов, ни интерфейсов нет. В SmallTalk нет понятия "допустимое сообщение".


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

если берем функцию js с кодом вида
function f(x)
{
  if (x == null || !x.length)
    return;
  ...
}

и простейшую классификацию: вырожденное/невырожденное поведение, то уже можно сказать, что объект x должен обладать интерфейсом вида (быть не null, и иметь поле length), чтобы функция f имела не вырожденное поведение.
и соответственно можно говорить о том, что в данном коде не явно зафиксировано каким интерфейсом обязан обладать объект x

S> Скажем, в JavaScript ни классов, ни интерфейсов нет.


с первым соглашусь
про второе корректнее сказать, что интерфейс в js есть, но он динамический (имеет возможность меняться по ходу работы программы)
хотя и прототип при определенных условиях можно рассматривать как динамический класс.
Re[118]: Immutable object
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 06.01.12 14:25
Оценка:
S>Да, вы правы — в базовой модели не требуется опознавать отправителя сообщения.

вернемся тогда к исходному коду с X, Y
void main()
{
  var x = new X();
  x.Message();
  
  var y = new Y();
  y.Message();
}

class X
{  
  public void Message(){}
}
class Y
{
  Y1 y1 = new Y1();
  public void Message(){y1.Message();}
}
class Y1
{
  public void Message(){}
}

в данном случае мы имеем 4 относительных наблюдателя:
main: наблюдает только, что объекты X и Y имеют одинаковое поведение: получают сообщение Message и ничего не делают
X: наблюдает только, что ему кто-то присылает сообщения Message
Y: наблюдает только, что ему кто-то присылает сообщение Message, что он в ответ на это посылает сообщение объекту Y1, который на это ничего не делает
Y1: наблюдает только, что ему кто-то присылает сообщение Message

и имея лишь эти наблюдения невозможно сделать вывод, что поведение объектов X и Y различно.
Re[74]: Immutable object
От: vdimas Россия  
Дата: 06.01.12 23:42
Оценка:
Здравствуйте, samius, Вы писали:

V>>Нет никакого порядка вызова printf() внутри реализации этой ф-ии, есть только одна эта задача на своем уровне, которая понятия не имеет о вызовах других printf().

S>Эта задача есть инструкция control flow. printf не учавствует в вычислении, в описании того что нужно получить.

Второе предложение можно по-русски?

V>>И есть некий низлежащий слой ОС. И эта задача вполне может быть выполнена без побочных эффектов на своем уровне, передавая данные "куда-то дальше"...

S>Передача данных "куда-то дальше" — это и есть императив. И нет никаких уровней побочных эффектов. Побочный эффект либо есть либо нет.

На уровне твоего кода его нет. Я не зря привел ф-ый язык как пример. Т.е. ты никак не можешь достоверно узнать, есть он или нет, бо на твои собственные программные примитивы это никак не влияет. Прямо как в ф-ом языке, где состояние-то есть, но тебе оно недоступно. Да, в случае printf есть требование последовательного исполнения, задаваемого в документации в ф-ии. Для сравнения, IO в Хаскеле задается явно в контракте ф-ии, в отличие от словесной доки по printf. Считай, что императивность сама по себе является элементом декларативности.

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

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

Э нет, за бортом ничего не остается, есть монады, задачи которых — именно образовать цепочку вычислений. Императив. И пусть это делается "чисто функциональными ср-вами" — ничего по-сути не меняется, коль нам гарантируется последовательность вычислений.

S>В сравнении с таким подходом, результатом выполнения main у C-подобных языков является int или void. И printf для вычисления этого значения не нужен.


При чем тут вообще main? В Хаскеле есть ввод-вывод куда угодно, в файл, сокет и т.д., вызываемые из произвольной IO ф-ии. Я пока не увидел, чем IO монада в Хаскеле отличается от тела ф-ии printf. Про State вообще молчу... эмуляция императива как оно есть.
Re[74]: Immutable object
От: vdimas Россия  
Дата: 07.01.12 03:44
Оценка:
Здравствуйте, Sinclair, Вы писали:

V>>Тем не менее, считается что сами уровни, подходящие под "как" и "что" находятся в односторонней зависимости, например, одному и тому же "что" может соответствовать много вариантов "как", каждый со своими лишними подробностями, не требуемыми на уровне "что". Мои рассуждения исходили из того, что на любом из вариантов уровня "как" видны примитивы уровня "что" (являются целью, "точкой входа" и т.д.), т.е. уровень "как" владеет одновременно своими подробностями и подробностями вышестоящей системы, в то время с уровня "что" подробности уровня "как" являются лишними.

S>Это интересное мнение. Откуда тогда так популярны соревнования типа "что делает эта программа", если на любом из вариантов уровня "как" видны примитивы уровня "что"?

Для 99% кода вполне понятно, что оно делает. И даже коментарий — это тоже часть программы, обычно описывающая ту часть контракта, которая невыразима ср-вами используемого ЯП.


V>>Нет никакого порядка вызова printf() внутри реализации этой ф-ии,

S>При чём тут реализация? Вы что, всеръёз полагаете, что результат
S>
S>printf("hello, ");
S>printf("world");
S>

S>и результат
S>
S>printf("hello, ");
S>printf("world");
S>

S>- одинаковы?

Для состояния твоей программы — несомненно одинаковы. Я ведь не зря привел пример ввода-вывода в ф-х языках.


V>>есть только одна эта задача на своем уровне, которая понятия не имеет о вызовах других printf(). И есть некий низлежащий слой ОС. И эта задача вполне может быть выполнена без побочных эффектов на своем уровне, передавая данные "куда-то дальше"...

S>Нет, она не может быть выполнена без побочных эффектов. Она целиком и полностью опирается на определённое поведение разделяемого состояния.

Это только у нас в голове так, согласно доке по консоли.


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

S>А вы поинтересуйтесь, как же так в чистых функциональных языках делают ввод-вывод. Там ведь нет ничего сложного — просто вместо неявного состояния вычислителя, на котором работают императивные программы, вводится явное состояние аргумента. Грубо говоря, вместо void printf(...) у нас появляется
S>
S>Console printf(this Console in, String text);
S>

S>Сама printf здесь не имеет побочных эффектов — её можно вызывать на одном и том же аргументе сколько угодно раз, и результат всегда будет одинаковым.

Дык, тело сишной printf тоже не имеет никаких побочных эффектов, является полностью реентерабельной. Если бы были побочные эффекты именно внутри кода printf, она не была бы реентерабельной и многопоточной. И да, в printf таки подается FILE (просто в той перегрузке, в которой не подается, используется глобальная переменная). И отличие в Хаскеля лишь в том, что IO-тип Console не надо возвращать обратно как результат ф-ии, бо это лишь частное требование для механики монады IO, которая не нужна в C++.

S>Чтобы задать порядок, надо явно писать

S>
S>console.printf("Hello").printf("World")
S>


Вооот... мы дошли до цепочек вычислений в ф-ом программировании, через механизм вложенных вызовов ф-ий, мне даже не пришлось 10-й раз намекать, как для случая РА. Чем не императив? ИМХО, только точкой зрения на происходящее.


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

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

Это ес-но, речь шла о том, где заканчивается декларативное и начинается императивное. Твои побочные эффекты могут быть нам недоступны, т.е. не влиять на элементы нашей программы, примерно как в монаде IO. В чем тогда отличие якобы декларативного Хаскеля в случае этой монады, и императивной программы, которая использует только "чистые" ф-ии и процедуры, не изменяющие неявно состояния нашей программы?

S>Единственный способ принудить инструкции исполняться последовательно — ввести зависимость их друг от друга. В императивном программировании зависимость вводится через побочные эффекты.


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


S>В декларативном программировании все зависимости — явные, поэтому можно делать всякие интересные трансформации с порядком выполнения (и с выполнением вообще).


Зависимости вложенных ф-ий конечно явные, задающие порядок вычислений.


S>В частности, можно вычислить первые N чисел Фибоначчи не за N^2, а за N, несмотря на явно рекурсивное определение этой функции.


Это св-во ленивости, а не ф-сти. Точно такой же эффект достижим и в императиве аж бегом, если навертишь свой некий тип Lazy<T>. Не смущает, что сам механизм ленивости основан на запоминании состояния в точке вычисления?


V>>Даже при взгляде на дерево вычислений математического выражения, в каждом узле этого дерева хранятся именно инструкции/операторы, которые вычисляются по направлению к корню.

S>Ну да, есть отношения частичного порядка, заданные зависимостями. Но для дерева с N листьями у нас есть минимум 2^N вариантов последовательности выполнения, если нет побочных эффектов. Если побочные эффекты есть, то у нас есть ровно 1 вариант последовательности, который даст заданный результат.

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

В общем, я еще с самого начала предупредил, что тема иммутабельности и границ императивности — скользкая. Много холивара и условностей, а львиная доля любой императивной программы — абсолютно чиста с т.з. побочных эффектов над доступными примитивами программы. Сказать, что я заведомо определился с какой-то точкой зрения не могу. В разных спорах участвую с разных сторон. Интересны сугубо аргументы. Бо сдается мне, что прямо на сегодня в этих понятиях слишком много религиозного и зависимости от точки зрения и глубины рассмотрения происходящего. А раз так, то использовать их в кач-ве аргументов следует осторожно или не использовать вообще, предпочитая обсуждать конкретику вместо приема спора, когда вопрос пытаются отнести к некоему "классу" и выстроеному последующему док-ву на принадлежности проблемы к сему классу.


V>>Это чтение одной строки в случае индекса имеет логарифмическую вид сложности некий K1 * O(log N), а чтение N страниц "вразнобой", а не подряд, имеет сложность O(N) cо своим совершенно другим К2, бо степень упорядоченность страниц данных обычно отличается от степени упорядоченности страниц индекса. Итого, логарифмический вид будет при малом K1, но прямо пропорционально при большем (обычно) K2.

S>Вы путаете разные N. Стоимость поиска одной строки — O(log N), где N — количество строк в отношении, в котором мы ищем.

Я именно это и сказал, никакой путаницы.

S>Стоимость поиска M строк, соответственно, равна O(M*log(N)).


Ага, вот где путаница, только не у меня. Для случая join мы имеем те же N, а не M (по крайней мере одна из сторон соединения просматривается целиком для любого из join).
Я словесно имел ввиду, что полная формула в пределе такая:
K1 * O(N * log N) + K2 * O(N), где K2 обычно гораздо гораздо хуже K1.



V>>Это бред сивой кобылы. Одну асимптотику можно выражать через другую, только если твой "другой" K постоянен, а если он зависит от того, сколько необходимых данных будут на каждой странице, то выражать одну сложность через другую бесполезно. В итоговую сложность надо будет включать отношения размеров доступного кеша и данных.

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

Очередной бред. При чем тут "пессимистика" и логические чтения? Ты понимаешь смысл символа O() в выражениях асимптотики? Чем отличается от O от Ω? Нет такого понятия "пессимистичная оценка". В терминах O идет ограничение асимптотики сверху. Вовсе не факт, что для реального объема данных, гораздо меньшего, чем в пределе, будет такая "песеммистическая оценка", обычно бывает ровно наоборот, зависимости для малого кол-ва данных обычно гораздо похуже, чем для асимптотики сверху. Ты этого не знаешь, поэтому порешь ерунду насчет "пессимистичности"... Ровно наоборот, оценка сверху зачастую — самая оптимистичная, т.к. для нее отбрасываются незначащие компоненты для бесконечно большого N. И эта оценка именно для логических чтений, независимо ни от какого cache hit ratio для твоих "больших размеров". Характерно, что для малого кол-ва данных тоже может случиться низкий cache hit ratio, например, если каждая страница в некоей выборке будет нужна лишь однажды, и не случится к ней того самого повторного обращения...


S>То есть наличие кэша всего лишь означает, что часть логических чтений удастся выполнить без физического обращения к диску. Вы сами предложили рассматривать случай, когда данные многократно превышают размер ОП — в этом случае сache hit ratio можно пренебречь, и считать, что он нулевой.


Оба предела асимптотики, выраженной в логических чтениях, что нижний, что верхний, никак не зависят от cache hit ratio. Ты сейчас подставляешься по самое нихочу, заканчивай умничать, где не ходил еще ни разу... Есть асимптотика в логических чтениях — я с ней и не спорю. Я лишь заметил, что оценка общей сложности может выглядеть иначе и это действительно так. Тем паче, что не сказал, какая именно асимптотика, а ты уже поскакал куда-то вдаль. ИМХО, дело тут тривиально в том, что реальную сложность трудно оценить абстрактно, а можно только на конкретных соотношениях характеристик ООП и данных, поэтому даются различные виды асимптотики, например, в терминах O для логических чтений. Но т.к. размеры современной ООП таковы, что отличаются от обычных данных уже не на несколько порядков, а дай бог на один, то эти характеристики начинают влиять на реальную сложность и их тоже интересно учитывать. Вот эти мои наблюдения относительно поведения кластерных индексов — они как раз насчет вполне осязаемых соотношений данных были даны, а не "асимптотически сверху", как выдавал рекомендации ты.

S>В этом случае у нас все коэффициенты станут фиксированными, их зависимостью от N и M можно будет пренебречь. И, конечно же, O(K1*M*logN+K2*M*logN) всё ещё сведётся к O(M*logN). Вы где вообще учились, что вам такие вещи приходится разжёвывать?


Позволь спросить, а ты где учился?
Фишка в том, что O(M*logN) не зависит от cache hit ratio даже для физических чтений, бо O — это ограничение асимптотики сверху. Но оценок может быть много, не обязательно оценка сверху. Ты же сам давал ссылку на что-то там по оценке сложности (хоть я и не ходил по ним, бо теорию, в отличии от, знаю неплохо, а оценка сложностей конкретных алгоритмов не интересует пока не столкнусь с ними). Так вот, в твоем оптимизаторе плана запросов фигурирует как раз не верхняя оценка асимптотики сложности, а именно реальная, без всяких O. Для того статистика и нужна, чтобы оперировать (пусть даже с некоторой погрешностью) заведомо известным кол-вом данных.


V>>Откуда "противник"? Я описал свои наблюдения относительно использования их в кач-ве уникальных ключей, где они хорошо работают, а где не очень. И как выяснилось в твоих же экспериментах, для "широких" таблиц кластерный индекс начинает работать как некластерный на чтении. Так зачем его тартить на это? Далее говорилось, что для небольших по-объему данных и "узкого" ключа основной ключ имеет смысл делать таки кластерным, невзирая ни на что. Т.е. я получал прирост эффективности для таких данных, невзирая на всевозможные join по совсем другим индексам. Возможно, хорошо начинают сказываться всякие политики упреждающего чтения, которые меньше промахиваются на малых объемах данных или еще что-нить, о чем можно только гадать. Т.е. возможны всякие эффекты, которые хрен увидишь в логических чтениях, но хорошо увидишь по возросшей отзывчивости основных операций после того как база немного "разогреется". Факт "разогрева" тоже простой асимптотикой логических чтений хрен опишешь...


S>Ваши наблюдения как были некорректными, так и остались.


Наблюдения — это объективная реальность.

V>>Гы, исследовать эффективность программных продуктов можно только на тестах в конкретном аппаратном окружении для конкретного характера данных... Остальное — грубая профанация.

S>>>Ну вот это уже больше похоже на правду. И прекрасно согласуется с теми критериями, которые я приводил 40 постов назад, а вы смеялись.
V>>Те критерии совершенно не объясняют устойчиво наблюдаемых эффектов. А в Санта-Клауса я не верю.
S>Ооо, начинается. Какие именно эффекты, необъяснимые приведёнными критериями, вы смогли получить? Не стесняйтесь — приведите код эксперимента.

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


V>>Таки это действительно MS настойчиво пишет в гайдах, и я не понял этот финт в кач-ве комментария. Ты точно на этот абзац отвечал, не промахнулся случаем?

S>Я отвечал на тот, где пачка смайликов, и вы пытаетесь смеяться над моим подходом. Объясню подробнее: вы уже две недели упорно демонстрируете непонимание простейших фактов из архитектуры MS SQL. В процессе объяснения этих элементарных фактов вы успели неоднократно сделать совершенно необоснованные предположения относительно моей квалификации, нарываясь на п.5. правил, и много смеялись. Теперь элементарные факты мы выяснили, несмотря на ваше активное сопротивление.

Да ладно тебе, своими "идите почитайте" ты нарываешься везде и всюду, где бы я не встречал твои посты. Заслужено получаешь в ответ. А здесь опять попытался сумничать не по теме обсуждения.

S>Вы продолжаете наезжать на моё понимание и опыт в СУБД, теперь переходя к эффектам следующего порядка.

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

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


V>>Для алгоритма перебора вариантов это не играет рояли.

S>О да. Интересное заблуждение.

Осталось продемонстрировать, что ты (а) таки понял утверждение, (б) оно не верно. ИМХО, если выполнишь (а), то (б) отпадет само собой.


V>>Давай конкретней, где ты это берешь?

S>Я дал вам ссылки на учебники по устройству СУБД. Читайте.

Дать тебе ссылку на устройство связанного списка?
Еще раз, как именно происходит преобразование структурных формул SQL к вариантам планов запросов, которые ЗАТЕМ оцениваются оценочной ф-ей. И таки частично ты прав, но скорее случайно, чем преднамеренно. Действительно, при переборе планов запросов некоторые ветки перебора могут отсекаться довольно рано, но это было бы известно тебе и так, если бы ты понимал, как именно эти планы строятся по выражениям SQL. И да, в твоей ссылке такой информации нет. Это надо топать в реляционные исчисления. Т.е. в школу, за азбукой. А потом уже садиться за "руководство программисту" к конкретному продукту и прочие твои ссылки "по разметке страниц в моей любимой СУБД".


V>>Эта информация (зависимости) есть на уровне реляционной модели by design, ничего расширять не надо.

S>Покажите мне, где эта информация есть на уровне реляционной модели. В реляционной модели понятие "отношения" достаточно чётко определено, и что там есть, и чего нету, написано очень подробно.

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


S>>>Почему недоступная-то? Всё доступно. Я ссылку на учебник дал. То, чего там нет, легко найти в публикациях. Просто применяемый аппарат шире, чем классическая РА.


Скука.

V>>Разбирать их целиком было невозможно принципиально, так что использовались в основном для непонятных моментов и эффектов, примерно как Reflector для дотнета. Исходники 6-ки таки были для гос-конторы.

S>В прошлый раз это было "вплоть до 2000".

В прошлый раз ты читал невнимательно. Вплоть до 2000 серьезно использовался MS SQL, начиная с шестерки. Потом крайне несерьезно, бо перешли на ORM, да и объемы данных для проектов были невелики, да и техника серьезно подросла, т.е. исследовательские работы по самой СУБД были не нужны. Т.е. опыта практически полной писанины приложения на СУБД и тщательного вылизывания эффективности больше не было (фигли для ORM вылизывать).


V>>Похоже, ты не понял, что есть копирование страниц в сравнении с работой через memory-mapping.

V>>http://msdn.microsoft.com/en-us/library/aa337560.aspx
V>>http://msdn.microsoft.com/en-us/library/aa337525.aspx

V>>Например:

V>>

V>>The buffer manager manages the functions for reading data or index pages from the database disk files into the buffer cache and writing modified pages back to disk.

V>>Запись целиком страницы обратно говорит о том, что, во первых это хреново, записывать 8k, если поменялся всего один байт (неважно, lazy там или еще что),
S>А вот конкретно это говорит о том, что вы не имеете представления о том, как работает чтение/запись в современных устройствах хранения (включая HDD и SSD).

Давай прежде посмотрим, как работает memory mapped file, а потом будем делать выводы.

S>Потому что записать меньше страницы на диск вообще нельзя. В теории СУБД традиционно принято оценивать характеристики в логических чтениях, а в практике — в IOPS. Современной аппаратуре всё равно, записать 1 байт или 1 екстент в 64кб.


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

В принципе, там суть не в IOPS, разумеется, а в том, что сервер, в отличие от ОС, знает, когда у него конец транзакции, поэтому использует копии страниц кеша, а не пользует память кеша страниц ОС напрямую, как в случае memory mapped file. Твои экстенты — они сугубо для уменьшения кол-ва дорогостоящих операций ввода/вывода, чтобы копировать за раз больше страниц... Но не на диск, разумеется, бо это не серверу решать (вот почему Oracle давно уже разраобтал свою файловую систему, чтобы держать всё под конторлем), а для того лишь, чтобы уменьшить кол-во системных вызовов, каждый из которых относительно дорогой (даже холостой вызов этого последовательного АПИ ввода-вывода стоит единицы микросекунд). И кстати, IOPS на SSD-массивах скоро будет уже под миллионы и выше, при том, что пропускная способность DMA ограничена, так что тебе стоит пересмотреть свои представления.
http://www.ixbt.com/news/hard/index.shtml?15/38/75

Основная фишка memory-mapped file в том, что в этом случае мы имеем меньше слоев IO, чем при последовательном способе, т.е. банально меньше копируется данных м/у дисковым кешем операционной системы и нашими буферами (страницами). Я уверен, что в MS SQL будет пересмотрен способ работы со страницами в ближайших версиях, бо сейчас их способ уже малость архаика.


V>>а во вторых, что сама страница не отображена как участок memory-mapped file, т.е. таки используется копия страницы в памяти. Хотя при BULK заливке или для твоих каких-то новых FILESTREAM (никогда не работал с ними) таки используется маппинг памяти на файлы (это видно по кодам ошибок), но при этом в журнал ничего не пишется и транзакционность не особо обеспечивается.

S>Вы сваливаете в одну кучу механику взаимодействия с файлом данных и с файлом журнала, а также понятие транзакционности. Там у вас тоже монолит, да?

Я думаю, это ты не способен адекватно воспринимать информацию. Тут я лишь подстраховался на случай возможных спекуляций, что таки MS SQL где-то использует упомянутую технологию. А что спекулировать навязчиво по какой-нить теме ты способен бесконечно — я это уже видел, в вопросе последовательности операций в РА.


V>>Ах, не сортировка? Что-то новое открыли в науке индексов? Или построение упорядоченной коллекции, типа сбалансированного дерева — это не сортировка? Как любопытно-то...

S>Сортировка. Но вы же поленились посмотреть стоимость этой сортировки.

Я знаю стоимость внешней сортировки уже более 20 лет как. Да, поленился в 1000-й посмотреть, потому что в верхнем пределе, том самом, которое при O, оно не может быть меньше.


S>>>И всё равно это будет O(N log N), только коэффициент будет учитывать и записи, и чтения.


V>>Только один коэф не сможет учесть-то, так что надо больше составляющих, и при каждой поставить свой коэф.

S>Вот у нас формула вида K1*N*logN + K2*N*logN. Вы правда думаете, что это не равно (K1+K2)*N*logN? Или у вас какое-то другое мнение о составляющих этой формулы?

Да, другое. Во втором компоненте будет просто K2*N.
"Идите учите" (С) внешнюю сортировку...

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


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

S>>>Да не будет никакой трубы. Будет O(N log N) c плохим коэффициентом. Ничего военного. Наличие большой ОП и разнесение на разные диски способны всего лишь улучшить коэффициенты, но не могут повлиять на асимптотику.


S>Ок, если вам хочется отбросить младшие члены ряда — пусть будет O(N). Несортированная сторона Join даст ещё M. Итого, имеем линейную асимптотику — O(N+M).

S>А вы, помнится, пугали меня O(N*M). Почувствуйте разницу.

Пффф, по кругу... Тебе осталось показать, что запись результата мощности O(N*M) будет дешевле сортировки одной из компонент.

S>>>Как раз в C# проблема с переполнениями детектируется элементарно. В отличие от менее удачных языков.

V>>Например? В С++ в компиляторах есть опция — проверять признак переполнения или нет.
S>Это в каких конкретно компиляторах? Или вы имеете в виду опции "отключить warning при возможном переполнении"?

В рантайм warning-ов не бывает, зато бывают исключения. А компиляторы? — все популярные.

S>В С# рекомендую курить ключевое слово checked.


OMG детсад. Я кажется начинаю понимать, откуда этот апломб... когда вокруг все кажутся гвоздями...
Был спрошен пример "менее удачных языков", и заранее приведен ответ. Ну чтобы итерации не растягивать. И это таки рантайм-детектирование — лажа, если честно. Да, на уровне файла можно задать это и для С++, т.е. не на уровне всей программы... В любом случае, останется только программу аккуратно закрыть и извиниться перед юзером... Только фигня это всё при наличии typedef в С++, бо можно написать обертку на любой тип и детектировать любые условия, которые твоему ограниченному checked и не снились. Бо шаблоны плюсов хорошо понимают глобальные и статические ф-ии и операторы, в отличии от генериков... Действительно полезно что-либо детектируется в статических анализаторах для C++. Есть статические анализаторы под C#, которые это же детектируют?


V>>Спасибо, просто открыл глаза...

S>Пожалуйста. Вы обращайтесь, если что.

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


V>>Я уже объяснил, откуда потенциальное попадание в ловушку — из-за специальной попытки избежать if.

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

Почему нет? А как, по-твоему, работает операция сравнения в аппаратуре? Для операции сложения/вычитания нужен всего один запасной разряд в любой базе, в двоичной в т.ч., это следует прямо из твоей математики без всяких-яких. Проблема в другом, в том, флаги переполнения недоступны в высокоуровневом ЯП кроме как через ветвление (хотя доступно их копирование в любой регистр во многих процах)... а ветвление жутко дорого.

Можно предложить такой вариант без if
int a, b;
int64 tmp = int64(a) — b;
return int32((tmp >> 1) | (tmp & 0x1));

Но это на основе конкретного двоичного представления. Если оно будет не таким как мы привыкли, работать не будет. Но не суть, ты пытался привести как пример одну модель, которая "не такая как другая". А это всё еще смешно выглядело, когда ты одну из ни назвал "чистой математикой", а другая какая, нечистая, что ле? Просто одна модель проще другой и всех делов. Та моя "другая" модель с шумами — она объективно существует, т.к. шум присутствует объективно в любом случае, пока не наступила тепловая смерть. Т.е. этот шум не был выдуман специально для погрешности квантования, ровно наоборот: погрешность квантования учитывается вполне объективно уже де-факто существующем аппаратом, оценивающим шум. Тоже самое в двоичном представлении чисел — это не "другая математика", это вполне проработанная модель, по которой все эффекты можно вывести на кончике пера, не ошибешься. А ошибки случаются лишь от того, что случайно (или специально) не учитывается модель целиком.
Re[75]: Immutable object
От: samius Япония http://sams-tricks.blogspot.com
Дата: 07.01.12 08:38
Оценка:
Здравствуйте, vdimas, Вы писали:

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


V>>>Нет никакого порядка вызова printf() внутри реализации этой ф-ии, есть только одна эта задача на своем уровне, которая понятия не имеет о вызовах других printf().

S>>Эта задача есть инструкция control flow. printf не учавствует в вычислении, в описании того что нужно получить.

V>Второе предложение можно по-русски?

Ссылаясь на определение декларативного программирования, я утверждаю что printf не описывает что нужно получить, т.к. void, ее результат есть ничто. Вместо этого printf воспроизводит побочный эффект. Т.е. вместо описания мы имеем инструкцию.

V>>>И есть некий низлежащий слой ОС. И эта задача вполне может быть выполнена без побочных эффектов на своем уровне, передавая данные "куда-то дальше"...

S>>Передача данных "куда-то дальше" — это и есть императив. И нет никаких уровней побочных эффектов. Побочный эффект либо есть либо нет.

V>На уровне твоего кода его нет. Я не зря привел ф-ый язык как пример.

Извини, ты привел в пример чистый ФЯ, при этом упоминаешь haskell. Что мне намекает на то, что ты не понимаешь природу вывода в хаскеле.
V>Т.е. ты никак не можешь достоверно узнать, есть он или нет, бо на твои собственные программные примитивы это никак не влияет.
В случае haskell я достоверно знаю что побочного эффекта нет. Описание main не производит побочный эффект.
V>Прямо как в ф-ом языке, где состояние-то есть, но тебе оно недоступно. Да, в случае printf есть требование последовательного исполнения, задаваемого в документации в ф-ии. Для сравнения, IO в Хаскеле задается явно в контракте ф-ии, в отличие от словесной доки по printf. Считай, что императивность сама по себе является элементом декларативности.
Тут я не понял, что ты написал, и что тебе забавно.

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


V>Э нет, за бортом ничего не остается, есть монады, задачи которых — именно образовать цепочку вычислений. Императив. И пусть это делается "чисто функциональными ср-вами" — ничего по-сути не меняется, коль нам гарантируется последовательность вычислений.

Не вижу связи между цепочкой вычислений и императивом. Композиция функций для тебя тоже императив?

S>>В сравнении с таким подходом, результатом выполнения main у C-подобных языков является int или void. И printf для вычисления этого значения не нужен.


V>При чем тут вообще main? В Хаскеле есть ввод-вывод куда угодно, в файл, сокет и т.д., вызываемые из произвольной IO ф-ии.

Ты что-то путаешь в отношении ввода-вывода хаскеля. Ввод-вывод не вызывается из произвольной функции. Или ты уже про бэкдоры типа unsafePerformIO ?

V>Я пока не увидел, чем IO монада в Хаскеле отличается от тела ф-ии printf.

Монада IO в хаскеле не производит побочный эффект, как это делает printf.
V>Про State вообще молчу... эмуляция императива как оно есть.
Эмуляция императива != императив. Хаскель описывает что нужно получить на выходе main. C описывает как нужно выводить в консоль, притом что на выходе этого описания return 0 в лучшем случае.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.