Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здравствуйте, WolfHound, Вы писали:
WH>>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>>Безопасность информационной системы вообще не зависит от используемого ЯП. WH>>Мы говорим про safe. Ты говоришь про secure. WH>>От того и непонимание.
KV>Перечитал еще раз. По-моему, netch80 говорит-таки о security, а не о safety, ибо:
KV>
KV>безопасность как понятие имеет смысл только при выставлении конкретных условий и ограничений, определения опасности и методов защиты от неё
Извини, это была всё-таки тема safety. Пардон за сбивание с толку, но базовые принципы применимы к обоим омонимам. Например, для C++ ты можешь обернуть доступ к объекту в мьютексы, но если кто-то полезет прямой модификацией памяти, никакая обёртка не поможет. И аналогичные ситуации и проблемы можно получить везде, хотя выглядеть будут существенно по-разному (например, для Erlang ты не залезешь в другой процесс, если он того не допустит, но можешь сбить с толку его взаимодействие с твоим процессом или организовать частичный DoS требованием ресурса). Более того, в этом аспекте security и safety сливаются в одно понятие — делать то, что можно (говоря по-бытовому), а различие между ними сокращается до вопроса источника возможной проблемы (внешний или внутренний).
WolfHound ругался на Go, утверждая, что его авторы явно врут про безопасность, хотя ничего для этого не делают. Я попытался объяснить, что такая безопасность, как он хочет, возможна, но чрезмерно ограничительна и расточительна; что есть много других методов, которые этим не страдают; наконец, что требовать безопасности от, например, доступа к глобальным переменным — вообще не имеет смысла для среды такого типа, как Go. Но меня, увы, просто не слышат.
The God is real, unless declared integer.
Re[45]: почему в вебе распространены именно динамические язы
V>Ведь что такое "тип"? Это способ разделения сущностей на сорта путем наделения их некими характеристиками (подробности зависят от конкретной системы типов). Типы существуют не забавы и этого спора ради, — это инструмент, который мы можем использовать для контроля корректности взаимодействия сущностей разных сортов, строя т.н. типизированные контракты. Причем, эти контракты будут проверяться автоматически. Т.е. в нашем распоряжении есть инструмент для избавления от таких явных проверок контрактов в рантайм, которые удастся описать с помощью системы типов, присутствующей в выбранном языке.
Я тут уже приводил пример. Есть такая лавка, JanRain. Они предлагают унифицированный логин через OpenID/MySpace/Twitter/Facebook и т.п. После логина пользователя они прислыают его профиль. Вот описание: https://rpxnow.com/docs#profile_data
Из 16 полей только 2 будут присутствовать всегда. Остальные — необязательные. Не говоря уже о том, что два из этих необязательных являются списком из других необязательных полей.
Ну и как, скажите мне, поможет мне статика при работе с этим данными? Да никак. Все выливается в итоге в if post.data contains field_1, if post.data contains field_2 и т.п.
Псевдокод
void process_request(Request req){
Profile profile = null;
if(req.contains("profile")){
profile = new Profile(req);
}
set_session_profile(req, profile);
}
void set_session_profile(Request req, Profile profile){
req.session.user.set_name(profile.get("formatted_name")); // вылетели к чертям в рантайме
}
Говнокод? Безусловно. Такого в природе не бывает? Бывает, и тоннами. Чем здесь поможет статическая типизация? Гарантировать, что на момент компиляции в функцию передаются параметры нужного типа?
Но и это тоже не всегда помогает. В статически типизированой Java при наличии полностью и без ошибок скомпилированного кода получаем ошибку приведения типов в рантайме.
Здравствуйте, Mamut, Вы писали:
M>Из 16 полей только 2 будут присутствовать всегда. Остальные — необязательные. Не говоря уже о том, что два из этих необязательных являются списком из других необязательных полей.
Достаточно создать сериализатор, понимающий тип option[T]:
[XmlElement("Profile")]
class Profile
{
[XmlElement("A")]
public RequiredField1 : string { get; set; }
[XmlElement("B")]
public RequiredField2 : int { get; set; }
[XmlElement("X")]
public OptionalField1 : option[string] { get; set; }
[XmlElement("Y")]
public OptionalField2 : option[int] { get; set; }
}
При доступе к опциональным полям компилятор заставит обрабатывать случаи отсутствия в них значения.
/* иЗвиНите зА неРовнЫй поЧерК */
Re[17]: почему в вебе распространены именно динамические язы
Здравствуйте, Воронков Василий, Вы писали:
VD>>Так что как не крути это еще одна попытка выдать сказки за чудесную действительность. VD>>Я уже устал повторять. Чудес не бывает. Скрипты дико медленны и могу использоваться только как клей для компонентов созданных на более быстрых средствах разрабоки. Компиляция скриптов конечно может несколько их ускорить, но в общем случае это ускорение не будет очень значительным в следствии динамической природы самих язков.
ВВ>Ты хочешь сказать, что если динамический язык компилируется, а не интерпретируется, то это не дает значительного ускорения?
Они и так все компилируются сначала во внутреннее представление. Важно, как происходят простейшие операции. Например, простое сложение, вместо вызова операции сложения двух регистров проца, динамически проверяет типы, приводит их к одному, потом уже выполняет операцию сложения. И не забываем, что в динамике у нас все лежит только на куче, даже простые целые числа. Вот эти две — основные причины тормозов.
Надо признать, что довольно шустро в динамике работают условные ветвления и циклы, фактически как в нейтиве, ибо ложь обычно представлена как null или как ссылка на некий заведомо известный атом #false, т.е., в зависимости от способа организации того самого промежуточного представления, можнонивелировать лишние затраты на эти популярные операции. Особенно циклы, если он поддержаны языком, а не реализованы на бестиповом while. Но вот с числовыми вычислениями — просто беда. Ну и не надо забывать про агрессивный инлайнинг что у того же С++, что у современных JIT.
Re[18]: почему в вебе распространены именно динамические язы
Здравствуйте, vdimas, Вы писали:
ВВ>>Ты хочешь сказать, что если динамический язык компилируется, а не интерпретируется, то это не дает значительного ускорения? V>Они и так все компилируются сначала во внутреннее представление.
Ну во-первых, не все. Если только "внутренним представлением" вы не называете AST. Потом — ну зачем придираться к словам? Понятно же, что я имею в виду.
V>Важно, как происходят простейшие операции. Например, простое сложение, вместо вызова операции сложения двух регистров проца, динамически проверяет типы, приводит их к одному, потом уже выполняет операцию сложения. И не забываем, что в динамике у нас все лежит только на куче, даже простые целые числа. Вот эти две — основные причины тормозов.
Вторая причина попросту невалидна. Нет никакого эксклюзивного требования у динамики хранить все только на куче, можно спокойно хранить примитивы на стеке. Первая проблема может быть устранена компилятором.
Re[27]: почему в вебе распространены именно динамические язы
M>>Из 16 полей только 2 будут присутствовать всегда. Остальные — необязательные. Не говоря уже о том, что два из этих необязательных являются списком из других необязательных полей.
H>Достаточно создать сериализатор, понимающий тип option[T]:
H>
H>[XmlElement("Profile")]
H>class Profile
H>{
H> [XmlElement("A")]
H> public RequiredField1 : string { get; set; }
H> [XmlElement("B")]
H> public RequiredField2 : int { get; set; }
H> [XmlElement("X")]
H> public OptionalField1 : option[string] { get; set; }
H> [XmlElement("Y")]
H> public OptionalField2 : option[int] { get; set; }
H>}
H>
H>При доступе к опциональным полям компилятор заставит обрабатывать случаи отсутствия в них значения.
А причем тут компилятор к рантайму? Это во-первых. Во-вторых, точно так же можно сделать и в динамике В-третьих, в указанной мною ситуации это вообще побоку, потому что если profile не будет, то программа вылетит в рантайме. Ну и в четвертых наличие статической типизации почему-то никак не помогло мне во втором примере
Возможности статики по гарантированию чего-либо сильно преувеличены в этом топике
Здравствуйте, Mamut, Вы писали:
M>А причем тут компилятор к рантайму?
При том, что компилятор не даст вызвать метод объекта, находящегося в Maybe, а если динамически типизированный язык не позволяет написать Nothing().FooBar(), то какой же он динамический?
M> Это во-первых. Во-вторых, точно так же можно сделать и в динамике
С.м. выше. Как сделать в динамике, чтобы нельзя было написать Nothing().FooBar()?
M> В-третьих, в указанной мною ситуации это вообще побоку, потому что если profile не будет, то программа вылетит в рантайме.
В каком смысле побоку?
M> Ну и в четвертых наличие статической типизации почему-то никак не помогло мне во втором примере
Во втором примере статическая типизация не используется.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[28]: почему в вебе распространены именно динамические язы
Здравствуйте, Mamut, Вы писали:
M>А причем тут компилятор к рантайму?
Потому что профиль наш строго типизирован и мы знаем какие поля могут принимать значение "нету".
M>Во-вторых, точно так же можно сделать и в динамике
Проверять на null?
M>В-третьих, в указанной мною ситуации это вообще побоку, потому что если profile не будет, то программа вылетит в рантайме.
Каков программист — такова и программа.
M>Ну и в четвертых наличие статической типизации почему-то никак не помогло мне во втором примере
Нам на этапе компиляции известны все поля, которые могут не содержать значение, таким образом мы объявляем их тип как option[T], где T — фактический тип поля. Правильно написанный десериализатор изготовит нам соответствующим образом проинициализированный объект.
Параметрический тип option[T] может принимать два значения: Some(t) и None(), где t — экземпляр типа T.
К фактическому значению некоторого поля мы можем добраться только тогда, когда это поле содержит значение Some(t), таким образом, каждый раз обращаясь к полю нам придется обрабатывать два случая: значение в поле есть (Some) и значения в нем нет (None). И то, что мы всегда в программе обрабатываем эти два случая проконтролирует компилятор.
/* иЗвиНите зА неРовнЫй поЧерК */
Re[29]: почему в вебе распространены именно динамические язы
M>>А причем тут компилятор к рантайму?
K>При том, что компилятор не даст вызвать метод объекта, находящегося в Maybe, а если динамически типизированный язык не позволяет написать Nothing().FooBar(), то какой же он динамический?
Ага. Это в теории. И, судя по Maybe, в хаскеле. Стоп. А откуда компилятор внезапно узнает, что там Maybe? Можно пример кода? Желательно, конечно не на Хаскеле, а на чем-то более приземленном, например на Java. Но на Хаскелле тоже сойдет.
M>> Это во-первых. Во-вторых, точно так же можно сделать и в динамике K>С.м. выше. Как сделать в динамике, чтобы нельзя было написать Nothing().FooBar()?
Точно так же как в статике Потому что даже в статике компилятор (анализатор? неонка?) не уверен, будет там null или нет.
Ловкость рук и никакого мошенничества (использую уже готовые типы из программы, но суть ясна). Язык — Java. IDE — JetBrains IDEA
Ошибка есть:
Икомпилятор выдает
Ошибка нет:
Компилятор выдает compiled successfully.
Но это же статика! Как такое может быть?
M>> В-третьих, в указанной мною ситуации это вообще побоку, потому что если profile не будет, то программа вылетит в рантайме. K>В каком смысле побоку?
В прямом. Компилятор не отловит этой ошибки. Или так — теоретически быть может в каком-то языке он ее отловит.
M>> Ну и в четвертых наличие статической типизации почему-то никак не помогло мне во втором примере
K>Во втором примере статическая типизация не используется.
С чего это вдруг? Все типы указаны, компилятор молчит Тут уже не один человек бъет себя пяткой в грудь и говорит, что компилятор от такого страхует
M>>А причем тут компилятор к рантайму? H>Потому что профиль наш строго типизирован и мы знаем какие поля могут принимать значение "нету".
M>>Во-вторых, точно так же можно сделать и в динамике H>Проверять на null?
Оставляю эо как домашнее задание.
M>>В-третьих, в указанной мною ситуации это вообще побоку, потому что если profile не будет, то программа вылетит в рантайме. H>Каков программист — такова и программа.
Это к вопросу не относится вообще никак. Имеем, что имеем. Тут мне рассказывают про чуда, а чуд как-то не получается.
M>>Ну и в четвертых наличие статической типизации почему-то никак не помогло мне во втором примере
H>Нам на этапе компиляции известны все поля, которые могут не содержать значение, таким образом мы объявляем их тип как option[T], где T — фактический тип поля. Правильно написанный десериализатор изготовит нам соответствующим образом проинициализированный объект.
H>Параметрический тип option[T] может принимать два значения: Some(t) и None(), где t — экземпляр типа T. H>К фактическому значению некоторого поля мы можем добраться только тогда, когда это поле содержит значение Some(t), таким образом, каждый раз обращаясь к полю нам придется обрабатывать два случая: значение в поле есть (Some) и значения в нем нет (None). И то, что мы всегда в программе обрабатываем эти два случая проконтролирует компилятор.
В примере не доступ к полям с null. Там попытка вызвать метод у null.
Здравствуйте, Mamut, Вы писали:
M>С чего это вдруг? Все типы указаны, компилятор молчит Тут уже не один человек бъет себя пяткой в грудь и говорит, что компилятор от такого страхует
О NotNull контрактах не так давно говорилось — системы типов JVM и CLR не поддерживают not-nullable ссылочных типов.
/* иЗвиНите зА неРовнЫй поЧерК */
Re[31]: почему в вебе распространены именно динамические язы
Здравствуйте, hardcase, Вы писали:
H>Здравствуйте, Mamut, Вы писали:
M>>С чего это вдруг? Все типы указаны, компилятор молчит Тут уже не один человек бъет себя пяткой в грудь и говорит, что компилятор от такого страхует
H>О NotNull контрактах не так давно говорилось — системы типов JVM и CLR не поддерживают not-nullable ссылочных типов.
Ну это совершенно не влияет на языки, которые работают на этих машинах.
В F#, например, есть not-nullable типы.
Re[31]: почему в вебе распространены именно динамические язы
M>>С чего это вдруг? Все типы указаны, компилятор молчит Тут уже не один человек бъет себя пяткой в грудь и говорит, что компилятор от такого страхует
H>О NotNull контрактах не так давно говорилось — системы типов JVM и CLR не поддерживают not-nullable ссылочных типов.
В итоге, что имеем в сухом остатке?
Изначальное заявление: Нам нужна статика.
В процессе допытывания выясняется, последовательно:
— Нет, нам нужна статика с хорошей системой типов.
— Нет, нам нужна статика с системой типов, поддерживающей все, что угодно — constraints, dependent types, контракты и т.п.
— Нет, нам нужна статика с системой типов, поддерживающей все, что угодно — constraints, dependent types, контракты и т.п., и желательно чтобы это был или Haskell или Nemerle.
И вот только тогда мы, быть может, сможем показать на практике те чудеса, которые мы вам обещали под эгидой «статика круче всегда!»
(со слов «Во-первых, о существующих средствах и текущих задачах»). И то как раз то, из-за чего тут разведено столько флейма. Нам обещают чудеса статики, но на практике этих чудес или не видно или видно только с кучей ограничений (типа «системы типов JVM и CLR не поддерживают not-nullable ссылочных типов»)
Здравствуйте, gandjustas, Вы писали:
H>>О NotNull контрактах не так давно говорилось — системы типов JVM и CLR не поддерживают not-nullable ссылочных типов.
G>Ну это совершенно не влияет на языки, которые работают на этих машинах.
Вообще-то влияет. Ка бы эта опция была — она была бы во всех языках на этих платформах, а сейчас же её достаточно проблематично реализовывать.
G>В F#, например, есть not-nullable типы.
Спс. Проясню этот вопрос.
/* иЗвиНите зА неРовнЫй поЧерК */
Re[33]: почему в вебе распространены именно динамические язы
Здравствуйте, hardcase, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
H>>>О NotNull контрактах не так давно говорилось — системы типов JVM и CLR не поддерживают not-nullable ссылочных типов.
G>>Ну это совершенно не влияет на языки, которые работают на этих машинах. H>Вообще-то влияет.
Вообще никак не влияет, это вопрос системы типов (компилятора, а не рантайма), компилятор может просто не предусматривать null значений. Или не допускать присваивания null для notnullable типов.
Re[30]: почему в вебе распространены именно динамические язы
Здравствуйте, Mamut, Вы писали:
K>>При том, что компилятор не даст вызвать метод объекта, находящегося в Maybe, а если динамически типизированный язык не позволяет написать Nothing().FooBar(), то какой же он динамический?
M>Ага. Это в теории.
Это если сделать допущение, что сейчас 1958-ой год, но сейчас 2010.
M>И, судя по Maybe, в хаскеле.
Особенно судя по словам "вызвать метод объекта".
M>Стоп. А откуда компилятор внезапно узнает, что там Maybe? Можно пример кода? Желательно, конечно не на Хаскеле, а на чем-то более приземленном, например на Java.
Пример на C# (Maybe придется написать самому (8 строчек) или скачать готовую)
from profile in GetProfile()
from result in ProcessRequest(profile)
select result;
Значение этого выражения Just(результат реквеста), если все прошло нормально или Nothing()
ProcessRequest(GetProfile());
Не скомпилируется.
Чудес бывает.
M>Точно так же как в статике Потому что даже в статике компилятор (анализатор? неонка?) не уверен, будет там null или нет.
Если у нас в языке есть null, то это означает, что то, имеем мы тип T или тип Maybe<T> определяется динамически. К статической типизации null никакого отношения не имеет.
K>>В каком смысле побоку? M>В прямом. Компилятор не отловит этой ошибки. Или так — теоретически быть может в каком-то языке он ее отловит.
На практике отловит в целом ряде языков.
K>>Во втором примере статическая типизация не используется. M>С чего это вдруг? Все типы указаны, компилятор молчит
Компилятор молчит, потому что программиcт заткнул ему рот явной декларацией отключения статической типизации. В коде она выделенна жирным шрифтом:
K>>>При том, что компилятор не даст вызвать метод объекта, находящегося в Maybe, а если динамически типизированный язык не позволяет написать Nothing().FooBar(), то какой же он динамический?
M>>Ага. Это в теории.
K>Это если сделать допущение, что сейчас 1958-ой год, но сейчас 2010.
Здравствуйте, gandjustas, Вы писали:
G>Вообще никак не влияет, это вопрос системы типов (компилятора, а не рантайма), компилятор может просто не предусматривать null значений. Или не допускать присваивания null для notnullable типов.
А вопрос получения подобного типа извне? Очевидное решение с автоматической проверкой на null кажется мне несколько непроизводительным.
/* иЗвиНите зА неРовнЫй поЧерК */
Re[32]: почему в вебе распространены именно динамические язы
Верно.
>В процессе допытывания выясняется, последовательно: >— Нет, нам нужна статика с хорошей системой типов.
Не так. "Даже статика с посредственной системой типов — уже лучше чем динамика, но нам нужна статика с хорошей системой типов"
>— Нет, нам нужна статика с системой типов, поддерживающей все, что угодно — constraints, dependent types, контракты и т.п.
Это было бы еще лучше, но почему "нет"? — с какой стати отказываться от предыдущих пунктов? Все логично — чем лучше система типов — тем лучше. Совершеннейший трюизм.
>— Нет, нам нужна статика с системой типов, поддерживающей все, что угодно — constraints, dependent types, контракты и т.п., и желательно чтобы это был или >Haskell или Nemerle.
Зависимых типов нет ни в Haskell, ни в Nemerle.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Да никак. Все выливается в итоге в if post.data contains field_1, if post.data contains field_2 и т.п.
