Сообщение Re[8]: В России опять напишут новый объектно-ориентированны от 11.02.2018 13:10
Изменено 12.02.2018 11:17 vdimas
Re[10]: В России опять напишут новый объектно-ориентированный
Здравствуйте, 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 как-то работает, верно?
Он обменивается строго-типизированными своими сообщениями.
Т.е. оба ендпоинта оперируют одними и теми же типами.
Т.е. опять ты проблематику не сформулировал.
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 как-то работает, верно?
Он обменивается строго-типизированными своими сообщениями.
Т.е. оба ендпоинта оперируют одними и теми же типами.
Т.е. опять ты проблематику не сформулировал.
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 как-то работает, верно?
Он обменивается строго-типизированными своими сообщениями.
Т.е. оба ендпоинта оперируют одними и теми же типами.
Т.е. опять ты проблематику не сформулировал.
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 как-то работает, верно?
Он обменивается строго-типизированными своими сообщениями.
Т.е. оба ендпоинта оперируют одними и теми же типами.
Т.е. опять ты проблематику не сформулировал.