Здравствуйте, vdimas, Вы писали:
V>Потому что SQL безбожно устарел и вообще
Это ты малость от жизни отстал. Несколько лет назад движуха была с криками "No SQL", потом стали тише говорить "Not only SQL", а сейчас все чаще слышно тихое "Not yet SQL"
V>в современной разработке является сущностью второго рода — производной генерируемой хренью/абракадаброй.
Здравствуйте, vdimas, Вы писали:
V>Потому что SQL безбожно устарел и вообще в современной разработке является сущностью второго рода — производной генерируемой хренью/абракадаброй.
Здравствуйте, MTD, Вы писали:
V>>Потому что SQL безбожно устарел и вообще MTD>Это ты малость от жизни отстал. Несколько лет назад движуха была с криками "No SQL"
Я эти крики слышал.
MTD>потом стали тише говорить "Not only SQL", а сейчас все чаще слышно тихое "Not yet SQL"
Это потому что нет подходящего языка.
Вернее, они есть, но не вышли за рамки "вещи в себе" некоторых NoSQL баз данных.
V>>в современной разработке является сущностью второго рода — производной генерируемой хренью/абракадаброй. MTD>Это только если нагрузка незначительная.
Ты имеешь ввиду ситуацию, когда SQL вообще представляется сущностю третьего рода, от бишь вовсе чужеродной хренью в программе, типа склеиваемых вручную строк? ))
Здравствуйте, Nikе, Вы писали:
V>>Потому что SQL безбожно устарел и вообще в современной разработке является сущностью второго рода — производной генерируемой хренью/абракадаброй. N>Люди которые это делают всё-равно некомпетентны.
Здравствуйте, vdimas, Вы писали:
V>>>Потому что SQL безбожно устарел и вообще в современной разработке является сущностью второго рода — производной генерируемой хренью/абракадаброй. N>>Люди которые это делают всё-равно некомпетентны.
V>Откуда инфа?
Здравствуйте, vdimas, Вы писали:
V>>>в современной разработке является сущностью второго рода — производной генерируемой хренью/абракадаброй. MTD>>Это только если нагрузка незначительная.
V>Ты имеешь ввиду ситуацию, когда SQL вообще представляется сущностю третьего рода, от бишь вовсе чужеродной хренью в программе, типа склеиваемых вручную строк? ))
Хренью тоже может быть — это уж как напишешь (пишут, ксати не только в программе, гугли хранимые процедуры). Но всякие ORM помимо проблем с производительностью, которые не решаются ни кешем первого, ни кешем n-ного уровня неправильны в принципе. Так как гвоздями прибивается часть бизнес-логики в виде сущностей к полям в таблицах. Почему это неправильно? Потому, что бизнес-логика изменчива и может меняться, а данные в базе — это данность, если Вася заплатил в 2010 году 100 рублей Пете, то это уже произошло и не изменится.
Здравствуйте, MTD, Вы писали:
V>>Ты имеешь ввиду ситуацию, когда SQL вообще представляется сущностю третьего рода, от бишь вовсе чужеродной хренью в программе, типа склеиваемых вручную строк? )) MTD>Хренью тоже может быть — это уж как напишешь (пишут, ксати не только в программе, гугли хранимые процедуры).
С какой целью гуглить хранимые процедуры?
И как это избавляет от строкового "{? = call proc_name(42, 43)}" или от "exec @ret=proc_name @param1=42, @param2=43"?
Даже если ты используешь некий "высокоуровневый объект" для вызова удалённых хранимок, это ничем не отличается от хелпера для формирования указанной строки.
MTD>Но всякие ORM помимо проблем с производительностью
Вот! Верно.
Потому что сущность второго рода.
Оптимизация компилятору недоступна, часто "компиляция" выполняется в рантайм.
Т.е. маппер генерируется по-месту, прежде чем начать что-то маппить.
А простые ORM, типа LinQ, и вовсе работают в режиме интерпретатора метаинформации для каждого поля каждой строчки, например, огромного рекордсета.
MTD>которые не решаются ни кешем первого, ни кешем n-ного уровня неправильны в принципе.
Это уже вопросы прикладного плана.
Где-то кеши уместны, где-то нет.
Но в базе должен быть эффективный и безопасный (в плане типов) инструмент.
А такого нет.
Т.е. вот отправляется запрос на сервер и уже оба ендпоинта должны заранее знать тип возвращаемого результата, а не гнать каждый раз метаинформацию и интерпретировать её на каждой из сторон.
MTD>Так как гвоздями прибивается часть бизнес-логики в виде сущностей к полям в таблицах.
Это тоже как раз нормально.
Данные есть данные.
Тут идёт разговор об удобном и эффективном оперировании данными.
MTD>Почему это неправильно? Потому, что бизнес-логика изменчива и может меняться, а данные в базе — это данность, если Вася заплатил в 2010 году 100 рублей Пете, то это уже произошло и не изменится.
Сам с собой споришь. ))
Так это "неправильно" или такова природа вещей?
Меня может тоже бесит, что котангес 𝜋 никак не может определиться — он плюс бесконечность или, всё-таки, минус бесконечность.
Но я ж смирился и живу с этим как-то...
Здравствуйте, vdimas, Вы писали:
V>С какой целью гуглить хранимые процедуры?
С целью расширения кругозора.
V>И как это избавляет от строкового "{? = call proc_name(42, 43)}" или от "exec @ret=proc_name @param1=42, @param2=43"?
А должно избавлять?
V>Даже если ты используешь некий "высокоуровневый объект" для вызова удалённых хранимок, это ничем не отличается от хелпера для формирования указанной строки.
И что? В чем проблема?
MTD>>Но всякие ORM помимо проблем с производительностью
V>Вот! Верно.
Я рад.
MTD>>которые не решаются ни кешем первого, ни кешем n-ного уровня неправильны в принципе.
V>Где-то кеши уместны, где-то нет.
Кеши уместны везде, другое дело, что их бывает недостаточно, а еще вместе с ними приходит и сложность.
V>Но в базе должен быть эффективный и безопасный (в плане типов) инструмент.
Да.
V>А такого нет.
Да.
V>Т.е. вот отправляется запрос на сервер и уже оба ендпоинта должны заранее знать тип возвращаемого результата
Естественно.
V>а не гнать каждый раз метаинформацию и интерпретировать её на каждой из сторон.
Зачем нужна метаинформация?
MTD>>Так как гвоздями прибивается часть бизнес-логики в виде сущностей к полям в таблицах.
V>Это тоже как раз нормально.
Нет. Почему я уже объяснил.
V>Тут идёт разговор об удобном и эффективном оперировании данными.
И? Твои тезисы?
V>Сам с собой споришь. ))
Не спорю, а объясняю, но видимо зря.
V>Но я ж смирился и живу с этим как-то...
Аминь.
Re[6]: В России опять напишут новый объектно-ориентированный
Здравствуйте, MTD, Вы писали:
V>>С какой целью гуглить хранимые процедуры? MTD>С целью расширения кругозора.
Будь конкретнее, плиз, в какую сторону надо расширять мой кругозор и чем он хуже твоего?
V>>И как это избавляет от строкового "{? = call proc_name(42, 43)}" или от "exec @ret=proc_name @param1=42, @param2=43"? MTD>А должно избавлять?
Разумеется.
На серверной стороне тоже.
Де-факто вся индустрия пользуется языком чуть ли не времён Фортрана с примерно таким же качеством его дизайна. Т.е. для своего времени язык был замечателен, требовал минимум ресурсов на его компилятор/интерпретатор, но морально устарел уже к концу 90-х.
V>>Даже если ты используешь некий "высокоуровневый объект" для вызова удалённых хранимок, это ничем не отличается от хелпера для формирования указанной строки. MTD>И что? В чем проблема?
В выразительных возможностях языка, в системе типов, в завязанной на этих моментах оссобеностях транспортного и прикладного уровня протоколов общения с БД и ничтожной в итоге эффективности всей системы.
MTD>>>которые не решаются ни кешем первого, ни кешем n-ного уровня неправильны в принципе. V>>Где-то кеши уместны, где-то нет. MTD>Кеши уместны везде, другое дело, что их бывает недостаточно, а еще вместе с ними приходит и сложность.
Это тебя опять тянет на прикладной уровень, а он зависит от конкетных сценариев, т.е. обобщать здесь бессмысленно.
Поэтому мы обсуждаем сугубо "механику", которая не зависит от прикладных моментов.
V>>Т.е. вот отправляется запрос на сервер и уже оба ендпоинта должны заранее знать тип возвращаемого результата MTD>Естественно. V>>а не гнать каждый раз метаинформацию и интерпретировать её на каждой из сторон. MTD>Зачем нужна метаинформация?
Зачем она нужна прямо сейчас? ))
Потому что имеет место динамическая типизация, это ж классика жанра.
MTD>>>Так как гвоздями прибивается часть бизнес-логики в виде сущностей к полям в таблицах. V>>Это тоже как раз нормально. MTD>Нет. Почему я уже объяснил.
Не объяснил.
Вопрос сам по себе не простой, твоё "объяснение" не потянуло даже на заголовок краткого обзора этого вопроса.
V>>Тут идёт разговор об удобном и эффективном оперировании данными. MTD>И? Твои тезисы?
Тезисы я озвучивал — перенос кучи телодвижений из рантайма в компайлтайм.
И отсюда иметь возможность по-настоящему заняться оптимизацией, типа как в современном С++.
MTD>Не спорю, а объясняю, но видимо зря.
На таком уровне, действительно, зря.
Путать прикладные сценарии со способами их реализации... ну я просто сижу и пытаюсь не улыбаться.
Здравствуйте, vdimas, Вы писали:
MTD>>С целью расширения кругозора.
V>Будь конкретнее, плиз, в какую сторону надо расширять мой кругозор и чем он хуже твоего?
Во все стороны, только очень тупой глупый считает, что ему кругозор расширять не надо. Мне естественно тоже расширять надо, так как я знаю, что много не знаю.
V>>>И как это избавляет от строкового "{? = call proc_name(42, 43)}" или от "exec @ret=proc_name @param1=42, @param2=43"? MTD>>А должно избавлять?
V>Разумеется. V>На серверной стороне тоже.
Как?
V>Де-факто вся индустрия пользуется языком чуть ли не времён Фортрана с примерно таким же качеством его дизайна. Т.е. для своего времени язык был замечателен, требовал минимум ресурсов на его компилятор/интерпретатор, но морально устарел уже к концу 90-х.
Критерии в студию.
V>>>Даже если ты используешь некий "высокоуровневый объект" для вызова удалённых хранимок, это ничем не отличается от хелпера для формирования указанной строки. MTD>>И что? В чем проблема?
V>В выразительных возможностях языка, в системе типов, в завязанной на этих моментах оссобеностях транспортного и прикладного уровня протоколов общения с БД и ничтожной в итоге эффективности всей системы.
Опять бла-бла-бла. Конкретней.
MTD>>Кеши уместны везде, другое дело, что их бывает недостаточно, а еще вместе с ними приходит и сложность.
V>Это тебя опять тянет на прикладной уровень, а он зависит от конкетных сценариев, т.е. обобщать здесь бессмысленно.
Меня никуда не тянет, ты решил поговорить ни о чем, я тебе помогаю подбрасывая тем.
V>>>Т.е. вот отправляется запрос на сервер и уже оба ендпоинта должны заранее знать тип возвращаемого результата MTD>>Естественно. V>>>а не гнать каждый раз метаинформацию и интерпретировать её на каждой из сторон. MTD>>Зачем нужна метаинформация?
V>Зачем она нужна прямо сейчас? )) V>Потому что имеет место динамическая типизация, это ж классика жанра.
Зачем нужна метаинформация?
V>Не объяснил.
Объяснил. Подумай немного, если что-то непонятно задай уточняющий вопрос.
V>>>Тут идёт разговор об удобном и эффективном оперировании данными. MTD>>И? Твои тезисы?
V>Тезисы я озвучивал — перенос кучи телодвижений из рантайма в компайлтайм.
Как?
V>И отсюда иметь возможность по-настоящему заняться оптимизацией, типа как в современном С++.
Вот есть файл, в нем лежат байты, на уровне байт нет никакой информации о высокоуровневых сущностях и логике. Или на примере сокета — сериализовали сущность в байты и кинули в сокет, на другой стороне достали и десиарилизовали, для этого оба участника должны знать информацию о типе, а по дороге это просто байты. Твои предложения?
V>Путать прикладные сценарии со способами их реализации... ну я просто сижу и пытаюсь не улыбаться.
Ну так не путай.
Re[8]: В России опять напишут новый объектно-ориентированны
Здравствуйте, MTD, Вы писали:
MTD>>>С целью расширения кругозора. V>>Будь конкретнее, плиз, в какую сторону надо расширять мой кругозор и чем он хуже твоего? MTD>Во все стороны, только очень тупой глупый считает, что ему кругозор расширять не надо.
Вопрос стоял не так, вопрос был — почему ты мне это посоветовал в этом обсуждении.
Что было не так?
V>>На серверной стороне тоже. MTD>Как?
Через типизированный язык.
В базе-то сидит реляционная алгебра, а она строго типизирована.
Отношения — они строго типизированы.
Соответственно, любой кортеж — тоже строго типизированный.
С учётом принятого в БД способа именнованного (а не позиционного) обращения к полям кортежей, можно напрямую использовать наработки из мейнстримовых языков, где в них описываются типизированные пользовательские структуры данных.
Это приведёт к еще одной разновидности оптимизации — повторному использованию кода, бо "тип" может быть отделён от "экземпляра", что тоже кардинально развяжет руки разработчикам. Потому что "мыслить категориями доменов" уместно далеко не во всех сценариях вокруг хранения данных. Я бы даже предположил — в подавляющем меньшинстве их.
V>>Де-факто вся индустрия пользуется языком чуть ли не времён Фортрана с примерно таким же качеством его дизайна. Т.е. для своего времени язык был замечателен, требовал минимум ресурсов на его компилятор/интерпретатор, но морально устарел уже к концу 90-х. MTD>Критерии в студию.
1. Типобезопасность, помощь со стороны компилятора;
2. Мощные, выразительные ср-ва языка;
3. Оптимизация, выкидывание лишних артефактов и лишних телодвижений;
В итоге — готовность работать с современными гигабитными сетками.
Мейнстримовые БД с такими сетками работать де-факто не готовы.
Сам я последние много лет работаю именно с протоколами удалённого доступа к данным.
Средний современный roundtrip (вопрос-ответ) составляет единицы микросекунд или единицы десятков их.
Поэтому, мне ОЧЕНЬ сложно участвовать в обсуждениях вокруг БД, где основными аргументами являются примерно такие: "да там всё равно СТОЛЬКО НАКЛАДНЫХ РАСХОДОВ, что экономить на спичках смысла нет".
Всё не так.
Причём, совершенно не так уже относительно давно.
Современные технологии как сетки, так и технологии работы БД с данными (особенно после "разогрева" с учётом нынешних чудовищных размеров оперативки) таковы, что основные тормоза приходятся именно на "интерфейсный" уровень БД. Этот уровень затормаживает всю систему в большинстве сценариев на порядок-другой.
V>>В выразительных возможностях языка, в системе типов, в завязанной на этих моментах оссобеностях транспортного и прикладного уровня протоколов общения с БД и ничтожной в итоге эффективности всей системы. MTD>Опять бла-бла-бла. Конкретней.
Это было более чем конкретно.
V>>Это тебя опять тянет на прикладной уровень, а он зависит от конкетных сценариев, т.е. обобщать здесь бессмысленно. MTD>Меня никуда не тянет, ты решил поговорить ни о чем, я тебе помогаю подбрасывая тем.
Я говорил о языке (или языках, не суть), предназначенном для обработки данных и инфраструктуре вокруг этого языка.
V>>Потому что имеет место динамическая типизация, это ж классика жанра. MTD>Зачем нужна метаинформация?
Зачем нужна метаинформация в случае динамической типизации я объяснять не буду.
Это хорошо объясняется на всех углах и без меня.
V>>Не объяснил. MTD>Объяснил. Подумай немного, если что-то непонятно задай уточняющий вопрос.
Тут надо было объяснить — о какой именно задаче идёт речь.
Но этого так и не прозвучало, соответственно, вопросы задавать не по чему.
Это ведь тоже классика жанра — уметь делать постановку задачи, т.е. формулировать проблематику.
Ты же высказался о проблематике решения, а не задачи.
Поэтому, низачОт. ))
V>>Тезисы я озвучивал — перенос кучи телодвижений из рантайма в компайлтайм. MTD>Как?
Как в С++, Java/Net, Swift и т.д.
V>>И отсюда иметь возможность по-настоящему заняться оптимизацией, типа как в современном С++. MTD>Вот есть файл, в нем лежат байты, на уровне байт нет никакой информации о высокоуровневых сущностях и логике.
Форматы хранения даных в различных БД открыты, спор ни о чём.
Сами данные хранятся как строго-типизированные.
У меня в объекте HashTable<ID, Record> или в Aray<Record> тоже нет никакой информации о "высокоуровневых сущностях и логике", но это не мешает компилятору оптимизировать все действия с такой структурой данных.
MTD>Или на примере сокета — сериализовали сущность в байты и кинули в сокет, на другой стороне достали и десиарилизовали, для этого оба участника должны знать информацию о типе, а по дороге это просто байты. Твои предложения?
Выделил жирным.
Ведь SSL как-то работает, верно?
Он обменивается строго-типизированными своими сообщениями.
Т.е. оба ендпоинта оперируют одними и теми же типами.
Т.е. опять ты проблематику не сформулировал.
Здравствуйте, vdimas, Вы писали:
V>Меня может тоже бесит, что котангес 𝜋 никак не может определиться — он плюс бесконечность или, всё-таки, минус бесконечность.
MTD>Но всякие ORM помимо проблем с производительностью, которые не решаются ни кешем первого, ни кешем n-ного уровня неправильны в принципе.
Много раз слышал от разных людей. Для начала пара слов про производительность. С производительностью проблема возникает от того, что ORM тупо не поддерживают плюхи конкретных СУБД. И приходится использовать нативный sql, чтобы их заюзать. С использованием нативного sql в некоторых местах в ORM проблем нет. В пределе, конечно, может быть надо будет отказаться от ORM совсем, но дойти до этого предела непросто, так как ORM упрощает 80% типовых операций и делает это хорошо. Других проблем с производительностью, специфичных только для ORM, у ORM нет.
MTD>Так как гвоздями прибивается часть бизнес-логики в виде сущностей к полям в таблицах.
Ну, не прибивай бизнес-логику к полям в таблицах. ORM не предполагает, что бы будешь это делать. По идее ORM занимается построением типовых запросов и отображением таблиц в объекты, в которых логики быть РЕШИТЕЛЬНО НЕ ДОЛЖНО. Прямо вот так, капсом . Объекты этим, соответственно, поведением не обладают и не инкапсулируют состояние и, следовательно, объектами в понимании ООП не являются, а являются структурами.
MTD>Почему это неправильно? Потому, что бизнес-логика изменчива и может меняться, а данные в базе — это данность, если Вася заплатил в 2010 году 100 рублей Пете, то это уже произошло и не изменится.
Бизнес логика, да, может меняться независимо от БД, поэтому, повторюсь нельзя помещать логику в объекты, отображением которых в БД занимается ORM. А лучше вообще не показывать эти объекты коду, который занимается бизнес-логикой. Данные в базе это данность, но вот структура БД может и будет меняться так же, как и бизнес логика. И очень удобно, когда можно менять одно независимо от другого.
Re[9]: В России опять напишут новый объектно-ориентированны
Здравствуйте, vdimas, Вы писали:
V>1. Типобезопасность, помощь со стороны компилятора; V>2. Мощные, выразительные ср-ва языка; V>3. Оптимизация, выкидывание лишних артефактов и лишних телодвижений;
LINQ не подходит?
Если нам не помогут, то мы тоже никого не пощадим.
Re[10]: В России опять напишут новый объектно-ориентированны
Здравствуйте, IT, Вы писали:
V>>1. Типобезопасность, помощь со стороны компилятора; V>>2. Мощные, выразительные ср-ва языка; V>>3. Оптимизация, выкидывание лишних артефактов и лишних телодвижений; IT>LINQ не подходит?
Внешний синтаксис вполне.
Промежуточное представление — мрак.
Дерево экспрешшенов в рантайме — хана всему.
Здравствуйте, vdimas, Вы писали:
V>>>На серверной стороне тоже. MTD>>Как?
V>Через типизированный язык. V>В базе-то сидит реляционная алгебра, а она строго типизирована. V>Отношения — они строго типизированы.
Я не понимаю, ты же сам пишешь, что на сервере уже все типизировано.
V>Это приведёт к еще одной разновидности оптимизации — повторному использованию кода, бо "тип" может быть отделён от "экземпляра", что тоже кардинально развяжет руки разработчикам. Потому что "мыслить категориями доменов" уместно далеко не во всех сценариях вокруг хранения данных. Я бы даже предположил — в подавляющем меньшинстве их.
Пример?
V>>>Де-факто вся индустрия пользуется языком чуть ли не времён Фортрана с примерно таким же качеством его дизайна.
V>1. Типобезопасность, помощь со стороны компилятора; V>2. Мощные, выразительные ср-ва языка; V>3. Оптимизация, выкидывание лишних артефактов и лишних телодвижений;
А чего из перечисленного нет в Фортране?
V>В итоге — готовность работать с современными гигабитными сетками. V>Мейнстримовые БД с такими сетками работать де-факто не готовы.
А все эти петабайты данных из астрала что-ли берутся? Ты вообще про что? Латенси, трупут? Ну и раз уж ты в теме дай-ка оценку производительности баз, дабы голословным не быть.
V>Сам я последние много лет работаю именно с протоколами удалённого доступа к данным. V>Средний современный roundtrip (вопрос-ответ) составляет единицы микросекунд или единицы десятков их.
Это булшит. Удаленный доступ может быть хоть голубиной почтой, естественно микросекунд там не будет.
V>Поэтому, мне ОЧЕНЬ сложно участвовать в обсуждениях вокруг БД, где основными аргументами являются примерно такие: "да там всё равно СТОЛЬКО НАКЛАДНЫХ РАСХОДОВ, что экономить на спичках смысла нет".
Я такое говорил? Нет? А к чему ты это написал?
V>Современные технологии как сетки, так и технологии работы БД с данными (особенно после "разогрева" с учётом нынешних чудовищных размеров оперативки) таковы, что основные тормоза приходятся именно на "интерфейсный" уровень БД. Этот уровень затормаживает всю систему в большинстве сценариев на порядок-другой.
Это полная чушь или уточни, что ты подразумеваешь под "интерфейсный".
V>>>В выразительных возможностях языка, в системе типов, в завязанной на этих моментах оссобеностях транспортного и прикладного уровня протоколов общения с БД и ничтожной в итоге эффективности всей системы. MTD>>Опять бла-бла-бла. Конкретней.
V>Это было более чем конкретно.
Нет — это бла-бла-бла.
V>Я говорил о языке (или языках, не суть), предназначенном для обработки данных и инфраструктуре вокруг этого языка.
Ну вот и говори про него, пока ничего конкретного не сказал.
V>>>Потому что имеет место динамическая типизация, это ж классика жанра. MTD>>Зачем нужна метаинформация?
V>Зачем нужна метаинформация в случае динамической типизации я объяснять не буду. V>Это хорошо объясняется на всех углах и без меня.
А при чем тут языки с динамической типизацией?
V>>>Тезисы я озвучивал — перенос кучи телодвижений из рантайма в компайлтайм. MTD>>Как?
V>Как в С++, Java/Net, Swift и т.д.
Мы про БД говорим. Как?
V>>>И отсюда иметь возможность по-настоящему заняться оптимизацией, типа как в современном С++. MTD>>Вот есть файл, в нем лежат байты, на уровне байт нет никакой информации о высокоуровневых сущностях и логике.
V>Форматы хранения даных в различных БД открыты, спор ни о чём.
Никто не спорит, тебе просто показали, что байты ни про какую типизацию не в курсе.
V>Сами данные хранятся как строго-типизированные. V>У меня в объекте HashTable<ID, Record> или в Aray<Record> тоже нет никакой информации о "высокоуровневых сущностях и логике", но это не мешает компилятору оптимизировать все действия с такой структурой данных.
Так и в БД все типизировано и не поверишь — там тоже есть оптимизатор. Твои идеи, или просто потрындеть?
MTD>>Или на примере сокета — сериализовали сущность в байты и кинули в сокет, на другой стороне достали и десиарилизовали, для этого оба участника должны знать информацию о типе, а по дороге это просто байты. Твои предложения?
V>Выделил жирным. V>Ведь SSL как-то работает, верно?
А он то причем?
V>Он обменивается строго-типизированными своими сообщениями.
А внутри байты. Файловая система тоже свою строго-типизированную информацию о файлах хранит.
V>Т.е. оба ендпоинта оперируют одними и теми же типами.
Отлично, речь то о чем?
V>Т.е. опять ты проблематику не сформулировал.
По моему ты увлекся беседой с выдуманным собеседником. Может со мной поговоришь? Начни для начала отвечать на заданные вопросы.
Если нам не помогут, то мы тоже никого не пощадим.
