Сообщение Re[6]: В России опять напишут новый объектно-ориентированный от 11.02.2018 9:50
Изменено 11.02.2018 10:04 vdimas
Re[8]: В России опять напишут новый объектно-ориентированный язык
Здравствуйте, 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>Не спорю, а объясняю, но видимо зря.
На таком уровне, действительно, зря.
Путать прикладные сценарии со способами их реализации... ну я просто сижу и пытаюсь не улыбаться.
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>Не спорю, а объясняю, но видимо зря.
На таком уровне, действительно, зря.
Путать прикладные сценарии со способами их реализации... ну я просто сижу и пытаюсь не улыбаться.
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>Не спорю, а объясняю, но видимо зря.
На таком уровне, действительно, зря.
Путать прикладные сценарии со способами их реализации... ну я просто сижу и пытаюсь не улыбаться.
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>Не спорю, а объясняю, но видимо зря.
На таком уровне, действительно, зря.
Путать прикладные сценарии со способами их реализации... ну я просто сижу и пытаюсь не улыбаться.