Сообщение Re[10]: В России опять напишут новый объектно-ориентированны от 13.02.2018 5:41
Изменено 13.02.2018 5:44 vdimas
Re[12]: В России опять напишут новый объектно-ориентированны
Здравствуйте, MTD, Вы писали:
V>>Через типизированный язык.
V>>В базе-то сидит реляционная алгебра, а она строго типизирована.
V>>Отношения — они строго типизированы.
MTD>Я не понимаю, ты же сам пишешь, что на сервере уже все типизировано.
Но язык доступа динамически типизированный.
V>>Это приведёт к еще одной разновидности оптимизации — повторному использованию кода, бо "тип" может быть отделён от "экземпляра", что тоже кардинально развяжет руки разработчикам. Потому что "мыслить категориями доменов" уместно далеко не во всех сценариях вокруг хранения данных. Я бы даже предположил — в подавляющем меньшинстве их.
MTD>Пример?
Кучи хранилищ данных с одинаковой разметкой таблиц.
Или кучи таблиц с одинаковой разметкой внутри одного хранилища.
V>>1. Типобезопасность, помощь со стороны компилятора;
V>>2. Мощные, выразительные ср-ва языка;
V>>3. Оптимизация, выкидывание лишних артефактов и лишних телодвижений;
MTD>А чего из перечисленного нет в Фортране?
1, 2
Система типов убогая.
V>>В итоге — готовность работать с современными гигабитными сетками.
V>>Мейнстримовые БД с такими сетками работать де-факто не готовы.
MTD>А все эти петабайты данных из астрала что-ли берутся?
С нормальной скоростью они только через bulk залетают.
V>>Сам я последние много лет работаю именно с протоколами удалённого доступа к данным.
V>>Средний современный roundtrip (вопрос-ответ) составляет единицы микросекунд или единицы десятков их.
MTD>Это булшит.
Сразу досвидан. ))
V>>Поэтому, мне ОЧЕНЬ сложно участвовать в обсуждениях вокруг БД, где основными аргументами являются примерно такие: "да там всё равно СТОЛЬКО НАКЛАДНЫХ РАСХОДОВ, что экономить на спичках смысла нет".
MTD>Я такое говорил? Нет? А к чему ты это написал?
Потому что это основной и единственный аргумент в обсуждениях такого рода.
Твой "булшит" тому подтверждение.
V>>Современные технологии как сетки, так и технологии работы БД с данными (особенно после "разогрева" с учётом нынешних чудовищных размеров оперативки) таковы, что основные тормоза приходятся именно на "интерфейсный" уровень БД. Этот уровень затормаживает всю систему в большинстве сценариев на порядок-другой.
MTD>Это полная чушь или уточни, что ты подразумеваешь под "интерфейсный".
Это весь комплекс телодвижений по вводу запроса и выводу результата.
V>>>>В выразительных возможностях языка, в системе типов, в завязанной на этих моментах оссобеностях транспортного и прикладного уровня протоколов общения с БД и ничтожной в итоге эффективности всей системы.
MTD>>>Опять бла-бла-бла. Конкретней.
V>>Это было более чем конкретно.
MTD>Нет — это бла-бла-бла.
Это через запятую перечислены ключевые моменты.
Спорь с этими моментами или слил.
V>>Я говорил о языке (или языках, не суть), предназначенном для обработки данных и инфраструктуре вокруг этого языка.
MTD>Ну вот и говори про него, пока ничего конкретного не сказал.
Сказано было достаточно — динамика vs статика.
V>>Зачем нужна метаинформация в случае динамической типизации я объяснять не буду.
V>>Это хорошо объясняется на всех углах и без меня.
MTD>А при чем тут языки с динамической типизацией?
При языке SQL и формате данных, пересылаемых по сети.
V>>>>Тезисы я озвучивал — перенос кучи телодвижений из рантайма в компайлтайм.
MTD>>>Как?
V>>Как в С++, Java/Net, Swift и т.д.
MTD>Мы про БД говорим. Как?
Мы про реляционную алгебру говорим.
Так же.
V>>Форматы хранения даных в различных БД открыты, спор ни о чём.
MTD>Никто не спорит, тебе просто показали, что байты ни про какую типизацию не в курсе.
Ты показал невежество.
Как и сообщением раньше:
Соблюдение типизации выражается в правильном интерпретировании эти байт.
Сейчас типизация динамическая, что влечёт за собой дополнительные расходы.
Например, на стороне клиента нужно динамически выбрать маппер из типа, хранимого в столбце, в тип переменной, куда это поле читается.
Там же, на стороне клиента, каждый раз приобращении к клиентскому драйверу при запросе значения некоторого поля текущей записи, драйвер тоже проверит — может ли он преобразовать тип данных в этом поле к запрашиваемому.
Т.е., мало того, что информация копируется малюсенькими куусочками — по одному значению одного поля каждый раз, так еще вокруг этого миллион телодвижений. При соблюдении же типизации можно сразу возращать ссылку на типизированное представление строки данных — некую структуру.
MTD>Так и в БД все типизировано и не поверишь — там тоже есть оптимизатор. Твои идеи, или просто потрындеть?
Пока не разберёшься, чем отличается статическая типизация от динамической — это будет разговор ни о чём.
Я лишь делился наблюдениями из своей предметной области, где зачастую весь прикладной трафик строго-типизированный.
MTD>По моему ты увлекся беседой с выдуманным собеседником. Может со мной поговоришь? Начни для начала отвечать на заданные вопросы.
Твои вопросы не относятся к сути моих предложений от слова никак. ))
Пока что ты пытаешься разобраться в отличии статики от динамики, но я уже отказался в этом участвовать (в прошлом сообщении).
V>>Через типизированный язык.
V>>В базе-то сидит реляционная алгебра, а она строго типизирована.
V>>Отношения — они строго типизированы.
MTD>Я не понимаю, ты же сам пишешь, что на сервере уже все типизировано.
Но язык доступа динамически типизированный.
V>>Это приведёт к еще одной разновидности оптимизации — повторному использованию кода, бо "тип" может быть отделён от "экземпляра", что тоже кардинально развяжет руки разработчикам. Потому что "мыслить категориями доменов" уместно далеко не во всех сценариях вокруг хранения данных. Я бы даже предположил — в подавляющем меньшинстве их.
MTD>Пример?
Кучи хранилищ данных с одинаковой разметкой таблиц.
Или кучи таблиц с одинаковой разметкой внутри одного хранилища.
V>>1. Типобезопасность, помощь со стороны компилятора;
V>>2. Мощные, выразительные ср-ва языка;
V>>3. Оптимизация, выкидывание лишних артефактов и лишних телодвижений;
MTD>А чего из перечисленного нет в Фортране?
1, 2
Система типов убогая.
V>>В итоге — готовность работать с современными гигабитными сетками.
V>>Мейнстримовые БД с такими сетками работать де-факто не готовы.
MTD>А все эти петабайты данных из астрала что-ли берутся?
С нормальной скоростью они только через bulk залетают.
V>>Сам я последние много лет работаю именно с протоколами удалённого доступа к данным.
V>>Средний современный roundtrip (вопрос-ответ) составляет единицы микросекунд или единицы десятков их.
MTD>Это булшит.
Сразу досвидан. ))
V>>Поэтому, мне ОЧЕНЬ сложно участвовать в обсуждениях вокруг БД, где основными аргументами являются примерно такие: "да там всё равно СТОЛЬКО НАКЛАДНЫХ РАСХОДОВ, что экономить на спичках смысла нет".
MTD>Я такое говорил? Нет? А к чему ты это написал?
Потому что это основной и единственный аргумент в обсуждениях такого рода.
Твой "булшит" тому подтверждение.
V>>Современные технологии как сетки, так и технологии работы БД с данными (особенно после "разогрева" с учётом нынешних чудовищных размеров оперативки) таковы, что основные тормоза приходятся именно на "интерфейсный" уровень БД. Этот уровень затормаживает всю систему в большинстве сценариев на порядок-другой.
MTD>Это полная чушь или уточни, что ты подразумеваешь под "интерфейсный".
Это весь комплекс телодвижений по вводу запроса и выводу результата.
V>>>>В выразительных возможностях языка, в системе типов, в завязанной на этих моментах оссобеностях транспортного и прикладного уровня протоколов общения с БД и ничтожной в итоге эффективности всей системы.
MTD>>>Опять бла-бла-бла. Конкретней.
V>>Это было более чем конкретно.
MTD>Нет — это бла-бла-бла.
Это через запятую перечислены ключевые моменты.
Спорь с этими моментами или слил.
V>>Я говорил о языке (или языках, не суть), предназначенном для обработки данных и инфраструктуре вокруг этого языка.
MTD>Ну вот и говори про него, пока ничего конкретного не сказал.
Сказано было достаточно — динамика vs статика.
V>>Зачем нужна метаинформация в случае динамической типизации я объяснять не буду.
V>>Это хорошо объясняется на всех углах и без меня.
MTD>А при чем тут языки с динамической типизацией?
При языке SQL и формате данных, пересылаемых по сети.
V>>>>Тезисы я озвучивал — перенос кучи телодвижений из рантайма в компайлтайм.
MTD>>>Как?
V>>Как в С++, Java/Net, Swift и т.д.
MTD>Мы про БД говорим. Как?
Мы про реляционную алгебру говорим.
Так же.
V>>Форматы хранения даных в различных БД открыты, спор ни о чём.
MTD>Никто не спорит, тебе просто показали, что байты ни про какую типизацию не в курсе.
Ты показал невежество.
Как и сообщением раньше:
В оперативной памяти тоже просто байты хранятся.Или на примере сокета — ... по дороге это просто байты
Соблюдение типизации выражается в правильном интерпретировании эти байт.
Сейчас типизация динамическая, что влечёт за собой дополнительные расходы.
Например, на стороне клиента нужно динамически выбрать маппер из типа, хранимого в столбце, в тип переменной, куда это поле читается.
Там же, на стороне клиента, каждый раз приобращении к клиентскому драйверу при запросе значения некоторого поля текущей записи, драйвер тоже проверит — может ли он преобразовать тип данных в этом поле к запрашиваемому.
Т.е., мало того, что информация копируется малюсенькими куусочками — по одному значению одного поля каждый раз, так еще вокруг этого миллион телодвижений. При соблюдении же типизации можно сразу возращать ссылку на типизированное представление строки данных — некую структуру.
MTD>Так и в БД все типизировано и не поверишь — там тоже есть оптимизатор. Твои идеи, или просто потрындеть?
Пока не разберёшься, чем отличается статическая типизация от динамической — это будет разговор ни о чём.
Я лишь делился наблюдениями из своей предметной области, где зачастую весь прикладной трафик строго-типизированный.
MTD>По моему ты увлекся беседой с выдуманным собеседником. Может со мной поговоришь? Начни для начала отвечать на заданные вопросы.
Твои вопросы не относятся к сути моих предложений от слова никак. ))
Пока что ты пытаешься разобраться в отличии статики от динамики, но я уже отказался в этом участвовать (в прошлом сообщении).
Re[12]: В России опять напишут новый объектно-ориентированны
Здравствуйте, MTD, Вы писали:
V>>Через типизированный язык.
V>>В базе-то сидит реляционная алгебра, а она строго типизирована.
V>>Отношения — они строго типизированы.
MTD>Я не понимаю, ты же сам пишешь, что на сервере уже все типизировано.
Но язык доступа динамически типизированный.
V>>Это приведёт к еще одной разновидности оптимизации — повторному использованию кода, бо "тип" может быть отделён от "экземпляра", что тоже кардинально развяжет руки разработчикам. Потому что "мыслить категориями доменов" уместно далеко не во всех сценариях вокруг хранения данных. Я бы даже предположил — в подавляющем меньшинстве их.
MTD>Пример?
Кучи хранилищ данных с одинаковой разметкой таблиц.
Или кучи таблиц с одинаковой разметкой внутри одного хранилища.
V>>1. Типобезопасность, помощь со стороны компилятора;
V>>2. Мощные, выразительные ср-ва языка;
V>>3. Оптимизация, выкидывание лишних артефактов и лишних телодвижений;
MTD>А чего из перечисленного нет в Фортране?
1, 2
Система типов убогая.
V>>В итоге — готовность работать с современными гигабитными сетками.
V>>Мейнстримовые БД с такими сетками работать де-факто не готовы.
MTD>А все эти петабайты данных из астрала что-ли берутся?
С нормальной скоростью они только через bulk залетают.
V>>Сам я последние много лет работаю именно с протоколами удалённого доступа к данным.
V>>Средний современный roundtrip (вопрос-ответ) составляет единицы микросекунд или единицы десятков их.
MTD>Это булшит.
Сразу досвидан. ))
V>>Поэтому, мне ОЧЕНЬ сложно участвовать в обсуждениях вокруг БД, где основными аргументами являются примерно такие: "да там всё равно СТОЛЬКО НАКЛАДНЫХ РАСХОДОВ, что экономить на спичках смысла нет".
MTD>Я такое говорил? Нет? А к чему ты это написал?
Потому что это основной и единственный аргумент в обсуждениях такого рода.
Твой "булшит" тому подтверждение.
V>>Современные технологии как сетки, так и технологии работы БД с данными (особенно после "разогрева" с учётом нынешних чудовищных размеров оперативки) таковы, что основные тормоза приходятся именно на "интерфейсный" уровень БД. Этот уровень затормаживает всю систему в большинстве сценариев на порядок-другой.
MTD>Это полная чушь или уточни, что ты подразумеваешь под "интерфейсный".
Это весь комплекс телодвижений по вводу запроса и выводу результата.
V>>>>В выразительных возможностях языка, в системе типов, в завязанной на этих моментах оссобеностях транспортного и прикладного уровня протоколов общения с БД и ничтожной в итоге эффективности всей системы.
MTD>>>Опять бла-бла-бла. Конкретней.
V>>Это было более чем конкретно.
MTD>Нет — это бла-бла-бла.
Это через запятую перечислены ключевые моменты.
Спорь с этими моментами или слил.
V>>Я говорил о языке (или языках, не суть), предназначенном для обработки данных и инфраструктуре вокруг этого языка.
MTD>Ну вот и говори про него, пока ничего конкретного не сказал.
Сказано было достаточно — динамика vs статика.
V>>Зачем нужна метаинформация в случае динамической типизации я объяснять не буду.
V>>Это хорошо объясняется на всех углах и без меня.
MTD>А при чем тут языки с динамической типизацией?
При языке SQL и формате данных, пересылаемых по сети.
V>>>>Тезисы я озвучивал — перенос кучи телодвижений из рантайма в компайлтайм.
MTD>>>Как?
V>>Как в С++, Java/Net, Swift и т.д.
MTD>Мы про БД говорим. Как?
Мы про реляционную алгебру говорим.
Так же.
V>>Форматы хранения даных в различных БД открыты, спор ни о чём.
MTD>Никто не спорит, тебе просто показали, что байты ни про какую типизацию не в курсе.
Ты показал невежество.
Как и сообщением раньше:
Соблюдение типизации выражается в правильном интерпретировании этих байт.
Сейчас типизация динамическая, что влечёт за собой дополнительные расходы.
Например, на стороне клиента нужно динамически выбрать маппер из типа, хранимого в столбце, в тип переменной, куда это поле читается.
Там же, на стороне клиента, каждый раз приобращении к клиентскому драйверу при запросе значения некоторого поля текущей записи, драйвер тоже проверит — может ли он преобразовать тип данных в этом поле к запрашиваемому.
Т.е., мало того, что информация копируется малюсенькими куусочками — по одному значению одного поля каждый раз, так еще вокруг этого миллион телодвижений. При соблюдении же типизации можно сразу возращать ссылку на типизированное представление строки данных — некую структуру.
MTD>Так и в БД все типизировано и не поверишь — там тоже есть оптимизатор. Твои идеи, или просто потрындеть?
Пока не разберёшься, чем отличается статическая типизация от динамической — это будет разговор ни о чём.
Я лишь делился наблюдениями из своей предметной области, где зачастую весь прикладной трафик строго-типизированный.
MTD>По моему ты увлекся беседой с выдуманным собеседником. Может со мной поговоришь? Начни для начала отвечать на заданные вопросы.
Твои вопросы не относятся к сути моих предложений от слова никак. ))
Пока что ты пытаешься разобраться в отличии статики от динамики, но я уже отказался в этом участвовать (в прошлом сообщении).
V>>Через типизированный язык.
V>>В базе-то сидит реляционная алгебра, а она строго типизирована.
V>>Отношения — они строго типизированы.
MTD>Я не понимаю, ты же сам пишешь, что на сервере уже все типизировано.
Но язык доступа динамически типизированный.
V>>Это приведёт к еще одной разновидности оптимизации — повторному использованию кода, бо "тип" может быть отделён от "экземпляра", что тоже кардинально развяжет руки разработчикам. Потому что "мыслить категориями доменов" уместно далеко не во всех сценариях вокруг хранения данных. Я бы даже предположил — в подавляющем меньшинстве их.
MTD>Пример?
Кучи хранилищ данных с одинаковой разметкой таблиц.
Или кучи таблиц с одинаковой разметкой внутри одного хранилища.
V>>1. Типобезопасность, помощь со стороны компилятора;
V>>2. Мощные, выразительные ср-ва языка;
V>>3. Оптимизация, выкидывание лишних артефактов и лишних телодвижений;
MTD>А чего из перечисленного нет в Фортране?
1, 2
Система типов убогая.
V>>В итоге — готовность работать с современными гигабитными сетками.
V>>Мейнстримовые БД с такими сетками работать де-факто не готовы.
MTD>А все эти петабайты данных из астрала что-ли берутся?
С нормальной скоростью они только через bulk залетают.
V>>Сам я последние много лет работаю именно с протоколами удалённого доступа к данным.
V>>Средний современный roundtrip (вопрос-ответ) составляет единицы микросекунд или единицы десятков их.
MTD>Это булшит.
Сразу досвидан. ))
V>>Поэтому, мне ОЧЕНЬ сложно участвовать в обсуждениях вокруг БД, где основными аргументами являются примерно такие: "да там всё равно СТОЛЬКО НАКЛАДНЫХ РАСХОДОВ, что экономить на спичках смысла нет".
MTD>Я такое говорил? Нет? А к чему ты это написал?
Потому что это основной и единственный аргумент в обсуждениях такого рода.
Твой "булшит" тому подтверждение.
V>>Современные технологии как сетки, так и технологии работы БД с данными (особенно после "разогрева" с учётом нынешних чудовищных размеров оперативки) таковы, что основные тормоза приходятся именно на "интерфейсный" уровень БД. Этот уровень затормаживает всю систему в большинстве сценариев на порядок-другой.
MTD>Это полная чушь или уточни, что ты подразумеваешь под "интерфейсный".
Это весь комплекс телодвижений по вводу запроса и выводу результата.
V>>>>В выразительных возможностях языка, в системе типов, в завязанной на этих моментах оссобеностях транспортного и прикладного уровня протоколов общения с БД и ничтожной в итоге эффективности всей системы.
MTD>>>Опять бла-бла-бла. Конкретней.
V>>Это было более чем конкретно.
MTD>Нет — это бла-бла-бла.
Это через запятую перечислены ключевые моменты.
Спорь с этими моментами или слил.
V>>Я говорил о языке (или языках, не суть), предназначенном для обработки данных и инфраструктуре вокруг этого языка.
MTD>Ну вот и говори про него, пока ничего конкретного не сказал.
Сказано было достаточно — динамика vs статика.
V>>Зачем нужна метаинформация в случае динамической типизации я объяснять не буду.
V>>Это хорошо объясняется на всех углах и без меня.
MTD>А при чем тут языки с динамической типизацией?
При языке SQL и формате данных, пересылаемых по сети.
V>>>>Тезисы я озвучивал — перенос кучи телодвижений из рантайма в компайлтайм.
MTD>>>Как?
V>>Как в С++, Java/Net, Swift и т.д.
MTD>Мы про БД говорим. Как?
Мы про реляционную алгебру говорим.
Так же.
V>>Форматы хранения даных в различных БД открыты, спор ни о чём.
MTD>Никто не спорит, тебе просто показали, что байты ни про какую типизацию не в курсе.
Ты показал невежество.
Как и сообщением раньше:
В оперативной памяти тоже просто байты хранятся.Или на примере сокета — ... по дороге это просто байты
Соблюдение типизации выражается в правильном интерпретировании этих байт.
Сейчас типизация динамическая, что влечёт за собой дополнительные расходы.
Например, на стороне клиента нужно динамически выбрать маппер из типа, хранимого в столбце, в тип переменной, куда это поле читается.
Там же, на стороне клиента, каждый раз приобращении к клиентскому драйверу при запросе значения некоторого поля текущей записи, драйвер тоже проверит — может ли он преобразовать тип данных в этом поле к запрашиваемому.
Т.е., мало того, что информация копируется малюсенькими куусочками — по одному значению одного поля каждый раз, так еще вокруг этого миллион телодвижений. При соблюдении же типизации можно сразу возращать ссылку на типизированное представление строки данных — некую структуру.
MTD>Так и в БД все типизировано и не поверишь — там тоже есть оптимизатор. Твои идеи, или просто потрындеть?
Пока не разберёшься, чем отличается статическая типизация от динамической — это будет разговор ни о чём.
Я лишь делился наблюдениями из своей предметной области, где зачастую весь прикладной трафик строго-типизированный.
MTD>По моему ты увлекся беседой с выдуманным собеседником. Может со мной поговоришь? Начни для начала отвечать на заданные вопросы.
Твои вопросы не относятся к сути моих предложений от слова никак. ))
Пока что ты пытаешься разобраться в отличии статики от динамики, но я уже отказался в этом участвовать (в прошлом сообщении).