Здравствуйте, eao197, Вы писали:

FR>>>>>Нифига списки вполне сопоставимые http://www.digitalmars.com/d/changelog.html и по ICE тоже. Похоже на самом деле ошибки больше зависят от квалификации пишущих а не от используемого языка.
K>>>>Надо учитывать, что компиляторы Scala и D по сложности, мягко говоря, сильно отличаются.
E>>>Ой-ли.
K>>Т.е. это не надо учитывать? Вы утверждаете, что можно сравнивать языки по багтрекерам двух разных проектов, которые писали разные люди, разное время и на разных языках? Методикой не поделитесь, очень интересно.

E>Мое "ой-ли" относилось к вашему утверждению о том, что сложность компиляторов Scala и D слишком различаются. По моему мнению, D вовсе не проще Scala, скорее наоборот.

Наоборот — это значит, что D сложнее, чем Scala? Но ведь смысл моего утверждения никак не зависит от того, что сложнее D или Scala (у меня есть мнение на этот счет, но обсуждать его мне не интересно, в основном потому, что хорошей методики определения сложности я не знаю, а обосновать свое интуитивное впечатление о сложности невозможно)
Смысл в том, что сложность различается.

E>Соответственно, и сложность компиляторов Scala и D не слишком различаются.

Что значит не слишком? Вы как сложность оцениваете? Когда она различается еще "не слишком", а когда уже "слишком"? А без методики можно только констатировать факт о том, что они различаются, а значит сравнения некорректны.

E>К тому же багтрекер, как ни крути, очень объективный показатель качества программного продукта (ну или разработчиков). Более объективный, может быть, чем мифические человеко-месяцы или KLOC-и.

С чего бы это? Объективным показателем был бы, например, баг на еденицу сложности (да и то только в том случае, если бы мы могли получить полный список багов, а не список известных на данный момент). Или баг на еденицу функциональности — что гораздо интереснее, ведь определеный уровень функциональности системы может быть достигнут, условно говоря, при любой сложности не меньше определенной. А в чем измерять сложность или функциональность компилятора? Число известных багов на KLOC или на мифический человеко-месяц посчитать легко, но зато о сложности компилятора KLOC-и и человеко-месяцы не очень хорошо говорят (в том случае, если писали разные люди и на разных языках — практически ничего не говорят.)
Я посмотрел багтрекеры GHC и Nemerle — для GHC я не нашел группировки по типу ошибки (крэш компилятора или нет — для данного случая), а в компиляторе Nemerle за всю его историю было найдено 45 крэшей, причем как минимум один из них — из-за бага в .NET CLR. Ну и какой из этого следует вывод?

Допустим, есть реализации стандарта (например C#) на C++ и на C#. Тут, на основании данных по строкам кода и человеко-часам еще можно какие-то выводы делать, а сравнивая баги в трекере D и Scala мы получаем, что в огороде бузина, а в Киеве — дядька. И что?

Здравствуйте, Klapaucius, Вы писали:

E>>Мое "ой-ли" относилось к вашему утверждению о том, что сложность компиляторов Scala и D слишком различаются. По моему мнению, D вовсе не проще Scala, скорее наоборот.

K>Наоборот — это значит, что D сложнее, чем Scala? Но ведь смысл моего утверждения никак не зависит от того, что сложнее D или Scala (у меня есть мнение на этот счет, но обсуждать его мне не интересно, в основном потому, что хорошей методики определения сложности я не знаю, а обосновать свое интуитивное впечатление о сложности невозможно)
K>Смысл в том, что сложность различается.

Угу, и эта сложность распределяется по разным взаимно-перпендикулярным осям, поэтому сравнивать ее никак невозможно.

E>>Соответственно, и сложность компиляторов Scala и D не слишком различаются.

K>Что значит не слишком? Вы как сложность оцениваете?

Как сложность реализации транслятора, на основании собственного небольшого опыта реализации нескольких лексических/семантических анализаторов и мелких языков.

E>>К тому же багтрекер, как ни крути, очень объективный показатель качества программного продукта (ну или разработчиков). Более объективный, может быть, чем мифические человеко-месяцы или KLOC-и.

K>С чего бы это?

Да так, просто. Жизненый опыт. Если в программе находя мало багов, то это говорит либо о ее качестве, либо о том, что ее мало используют. Если же багов много, то не так уж важно, насколько много и широко ее используют -- их количество говорит о качестве.

Но я не могу говорить о проектах в миллионы строк (вроде Windows), там мало багов быть по определению не может.

K>Я посмотрел багтрекеры GHC и Nemerle — для GHC я не нашел группировки по типу ошибки (крэш компилятора или нет — для данного случая), а в компиляторе Nemerle за всю его историю было найдено 45 крэшей, причем как минимум один из них — из-за бага в .NET CLR. Ну и какой из этого следует вывод?

А какой вывод вы хотели? Посмотрите на название темы. Я действительно не понимаю, почему на безопасной JVM и высокоуровневых языках Java и Scala в компиляторе Scala находят столько крэшей. Вот и по вашим данным в Nemerle их за всю историю нашли всего 45. А тут только после RC1 двадцать штук.

K>Допустим, есть реализации стандарта (например C#) на C++ и на C#. Тут, на основании данных по строкам кода и человеко-часам еще можно какие-то выводы делать, а сравнивая баги в трекере D и Scala мы получаем, что в огороде бузина, а в Киеве — дядька. И что?

А то и получаем -- качественные программы зависят от качественных программистов. Хороший инструмент нормальному разработчику только в помощь будет, а другому -- что Scala, что C++, все равно крэш на крэше.

Здравствуйте, eao197, Вы писали:

E>Scala, вероятно, посложнее Turbo C (ой ли). Но уж явно не сложнее MultiEdit-а.

Здравствуйте, eao197, Вы писали:

>... ChangeLog языка Scala ...
E>Проблема в том, что существует поверье, мол чем выше язык, тем более сложные задачи он позволяет решать. А более простые задачи позволяет решать проше и быстрее. Так вот, больше всего меня интересует, раз Scala сейчас вбирает в себя все лучшее и работают над ним совсем не глупые люди, почему же у них в ChangeLog-е после первого релиз кандидата (это все-таки не бэта даже, а почти релиз) критические ошибки десятками вылазюют. Не сильно-то, видно, облегчает.

Смотрим этот лог...
Первая ошибка связана с ошибкой в паттерн-матчинге. Тут вина в том, что язык доупскает пдобное. Прчем делает это довольно легко. В том же Немерле приняли решение по умолчанию использовать закрытые типы и проверки на полноту матчей. В прочем достаточно добавить образец "_" и с ним сопоставится все что угодно (контроль будет выключен).
Вторая — это банальное срабатывание ассерта.
Третья — NullPointerException. Одна из главнеших проблем всех мэйнстрим-лайк (так чтоли их назвать) языков. Точнее языков с С++-подобной системой типов основаной на классах и их экземлярах. Подобное невозможно в Хаскеле или МЛ, но и там могут быть проблемы с option/mayby.
Следующий (#29) — опять ассерт сработал.
#28 — ошибка в компиляторе выявленная исключением. Считай тот же ассерт.

Дальше влом смотреть. Ясно что это банальные ошибки выявленные при тестировании.

Видмо сбивает с толку слово "краш".
Лично я согласен с palm mute. Это именно что ошибки выяляемые в процессе тестирования.
Сравнивать же тут что-то с С++ просто бесмысленно. Объем кода на этом языке был бы в разы (а то и порядки) больше и проблем, соотвественно, было бы так же больше. Причем краши были бы уже не исключениями, а веселыми падениями с порчей памяти (не все, конечно, но многие).

E>А что не было релиза, так это не показатель -- можно глянуть предыдущие версии, крэшей и там после релизов найти можно порядком.

Все программы глючат. Сложные — тем более.

В общем, эту тему можно расценивать как еще дин бессмысленный флэйм. Эдакая разновдность кидания дерьма на вентилятор. Весело, много шума и мата...

Здравствуйте, FR, Вы писали:

FR>Нифига списки вполне сопоставимые http://www.digitalmars.com/d/changelog.html и по ICE тоже.

Сравнивать надо схожие по сложности вещи. Вот Немреле и Скала сравнимы. Ди еще до них расти и расти.
У Ди только один показатель похож — объем кода компилятора. Так что это скорее подтверждает империческое правило, что объем ошибок примерно одинаков и пропорционален объему кода (больеш код, больше ошибок). И то что на более мощьных языках проще писать более сложные вещи.

FR>Похоже на самом деле ошибки больше зависят от квалификации пишущих а не от используемого языка.

От квалификации конечно объем ошибок завсит очень сильно. Чем она выше, тем их меньше, и тем они страшнее. Но вот от языка зависит еще объем решения и его понятность. А от этих фаторов зависит и объем ошибок. Если одну и ту же задачу попытаться релаизовать на менее мощьных (Ди, С++ и т.п.) и на языках более мощьных (каждый подставляет свой любимый), то объем решения (при грамотной реализации, конечно) будет существенно различатьс, а стало быть будет различаться и количество ошибок.

Здравствуйте, eao197, Вы писали:

E>Мое "ой-ли" относилось к вашему утверждению о том, что сложность компиляторов Scala и D слишком различаются.

Как человек занимающийся компилятором похожего языка подтверждаю, что компиляторы языков Scala и D очень сильно разничаются по сложности. И это различие не в пользу Ди.

E>По моему мнению, D вовсе не проще Scala, скорее наоборот. Соответственно, и сложность компиляторов Scala и D не слишком различаются.

Твое мнение вообще не ясно откуда взялось.
В Ди нет половины фич, что есть в Скале. А те что есть реализованы не полностью. Или мод сложностью Ди ты понимашь трудность программирования на нем?

E>К тому же багтрекер, как ни крути, очень объективный показатель качества программного продукта (ну или разработчиков). Более объективный, может быть, чем мифические человеко-месяцы или KLOC-и.

Багтрекер — показатель качества?
Это значит, что чем меньше список исправленных багов, тем надежнее продукт?

Здравствуйте, MatFiz, Вы писали:

MF>Я утверждаю только то, что код, написанный с трудом,- некачественный, ибо и поддерживать его придется с трудом.

Скажи, нужен ли труд (усилия), чтобы грамотно выделить абстракции, даеть хорошие (краткие, но понятные) имена методам и переменным, найти и применить наиболее подходящие готовые универсальные фукнции (а не накатать свои частные решения) и т.п.?

Вот об этом, как я понимаю EvilChild-а, он и говорит когда говорит о сложности. Всегда проще накатать код, что называется, в столбик. Поддерживать и развивать такой код будет мукой, но написать его будет проще.

Здравствуйте, mkizub, Вы писали:

M>И что? buf явно проинициализирован. Тот, кто не прочитал спецификацию на возвращаемое значение — сам дурак.
M>Этот код точно так-же пишется на С/С++, только он выкинет не exception, а core dump.

На самом деле вы оба не правы.

Конечно Ява в сто раз безопаснее С++, так как просто недопускает порчи памяти и связанной с ней мучительной отладке наугад. Тут ты прав, а еао197 не прав.

Но, NPE (NullPointerException) — это огромный геморой современного мэйнстрима. И проблема в основном заключается в том, что null появляется там где программист о нем не подозревает.

Если быть более точным, то проблма кроется еще глубже. В современных мэйнстрим-языках отсуствует четкая семантика понятия необъязательный. NULL/null/0 зачастую используется как высокопроизводительная форма сообщить вызваашей стороне, что что-то отсусвтвует или не определено. То есть NULL/null/0 неформально получают семантику Optional/Default/Nothing/Error. Нигде кроме документации (которой может и не быть) подобные предположения (а как их еще назвать?) не описывают. В других же местах программист (чтобы упростить себе жизнь) считает, что сылка всегда указывает на что-то осмысленно. Ошибка в подобных предположениях в купе с забывчивостью и приводят к ошибкам.

Да ошибки, что называется, по дурости. Но уд больно они распространены.

В С++ есть возможность семантически указать, что, например, в качестве параметра должна передаваться ссылка на реальный объект. Понятно что речь идет о ссылках появившихся в С++. Однако это всего лишь метод избавиться от ошибок в конкретных местах. Сам язык никак не предотвращает программирования без ссылок и более того содержит ряд дефектов дизайна приводящих к тому, что проблемы с указателями могут возникнуть и в участках кода которые формально корректные (прямая работа с указателями, порча памти в виду опасных приведений типов и т.п.). В итоге писать реальные приложения на С++ значительно сложнее чем на Яве. А то кто смеет утверждать обратное или очень сильно заблужадется, или намеренно врет.

Так вот в той же Скале тоже есть средство позволяющее явно указать семантику не "Optional". Незнаю как оно там назвается, но аналог в Немрле называется option[T]. Идея очень проста. Мы возвращаем не ссылку на объект типа T которая может быть null, а ссылку на option[T] (вариант который может иметь два значения Some(x : T) или None(). Далее обрабатывает их средствами паттерн-матчинга). Все остальные ссылки считаются недопускающими null. Так сделано в Хаскеле и вообще опчти всех клонах МЛ. Вот только одно "но". В виду совместимости с Явой и в следствии борьбы за производительность (ведь null дешевле чем лишняя косвенность и лишний оберточный объект), и Скала, и Немрерле не запрещают использование null-ссылок. Отслеживает ошибки только рантайм (компилятор тут бессилен, так как система типов не только допускает null-значения, но и инициализирует все ссылочные поля и переменные в null по умолчению).

Собственно средства борьбы уже готовится. В Spec# реализован аппорат контроля допустимости null во время компиляции. При этом система типов расширена типами !T аналогичной T но недопускающей null, а хитрая система проверки корректности теорем строит теоремы доказывающие корректное использование ссылок и проверяет их корректность. В эксперементальном режиме данная фича доступна и в Немерле. Но для ее использования прийдется понапрягаться (скачать и установить Spec#, подключить нестандратные пространства имен содержащих интеграцию и т.п.). Однако и при этом прийдтя немало времени уделить аннотациям типов, а результат не всгеда бует качественным.

Одитоживая скажу, что фактически проблема некорректных ссылок существует и в С++, и в Яве/дотнете, причем в С++ она имеет более дорогую цену, а единственным средством борьбы с проблемой является аккуратность программиста и соблюдение им разного рода паттернов программирования вроде исползования ссылок и смартпоинтров вместо указателей. Подобные техники есть и для Явы, но Ява все же, гарантирует целостность памяти, а значит снижает цену ошибки.

Хорошим выходом из ситуации было бы:
1. Отказаться от null в системе типов.
2. Ввести в систему типов аналог option[T] (нулабл-типы из дотнета не подходят, так как они применимы исключительно для вэйлью-типов).
3. Заставить программиста явно указывать, что ему нужен option[T]-тип, в тех местах где программист ранее передавал null в качестве некоторого сигнала.
4. Заставить компилятор требовать инициализации всех перменных не null-значениями.

Вот только это серьезное изменение и не только в компиляторах.

Как вариант — внедрить в жизнь технологии аля Spec#. Но пока что до этого далеко.

Здравствуйте, FR, Вы писали:

FR>Угу, имеет значение совсем другое. Насколько я понимаю в java любому объекту можно присвоить null. В С++ нет. И соответственно число ошибок обращения по нулевому указателю должно быть меньше. Ну и тот же RAII над которым так любят посмеятся поклоники манджед сред тоже имеет значение.

И тем не менее С++-программы вылетают по AV пожалуй чаще всего.
И дело тут в том, что в С++ есть 101 способ сделать ошибку связаннаю с указателями. В том числе тому способствует отсуствие гарантированной инициализции и мухлеж с типами. Причем последствия получаются куда страшнее чем NPE.

ЗЫ

NPE я не защищаю. Грамотным решением проблемы считаю подход МЛ-ь подобных языкво — введние специального типа для инкапсуляции значений которые могут быть неопределены и полный запрет на использование null. В прочем, без обязательной инициализации переменных и без отказа от

Здравствуйте, eao197, Вы писали:

E>>>В одной раз забабахали утверждения, что managed-языки и ФП -- рулез.

IT>>Детский сад, штаны на лямках. Я ведь я тебя считал почти взрослым человеком.

E>Я просто очень большой ребенок А любимые игрушки -- велосипеды

Это было не странное если не одно "но". Нормальные дети любят кататься на велосипедах, а не зацикливаются на их изобретении.

Здравствуйте, VladD2, Вы писали:

VD>Хорошим выходом из ситуации было бы:
VD>1. Отказаться от null в системе типов.

Нереально. То есть можно "как правило" отказаться (введя "пустой объект" данного класса, скажем пустую строку для строк), за исключением небольшого числа случаев (0 тоже долго не считали числом, но потом решили, что уж слишком удобное понятие).
Но это будет не сильно большим выходом, ошибки NPE сейчас — чаще всего замаскированная другая ошибка. В каком-то смысле NPE — это автоматически расставляемые компилятором/VM ассерты. Не будет NPE — будут ещё более трудно уловимые баги.

VD>2. Ввести в систему типов аналог option[T] (нулабл-типы из дотнета не подходят, так как они применимы исключительно для вэйлью-типов).

Не очень удобно, IMHO, так как не-null можно рассматривать как один из constraint-ов данных. Могут быть и другие условия, вроде interned объектов (которые можно сравнивать на равенство по ссылке, а не по значению). Если на одину ссылку наложить несколько условий — то не понятно в каком порядке их "оборачивать" в эти врапперы.

VD>3. Заставить программиста явно указывать, что ему нужен option[T]-тип, в тех местах где программист ранее передавал null в качестве некоторого сигнала.

И чтоб это было опционально. То есть программист мог включать для отдельных модулей проверку на NPE, и эта ошибка тогда будет проверяться на стадии компиляции.

VD>4. Заставить компилятор требовать инициализации всех перменных не null-значениями.

Что невозможно, по причинам (1). Или тогда надо делать это эквивалентным (2).

VD>Как вариант — внедрить в жизнь технологии аля Spec#. Но пока что до этого далеко.

Надо почитать что у них там...

Здравствуйте, mkizub, Вы писали:

M>Нереально. То есть можно "как правило" отказаться (введя "пустой объект" данного класса, скажем пустую строку для строк), за исключением небольшого числа случаев (0 тоже долго не считали числом, но потом решили, что уж слишком удобное понятие).
Так Влад и предлагает ввести пустой объект "соседнего" класса.

M>Но это будет не сильно большим выходом, ошибки NPE сейчас — чаще всего замаскированная другая ошибка. В каком-то смысле NPE — это автоматически расставляемые компилятором/VM ассерты. Не будет NPE — будут ещё более трудно уловимые баги.
Нет, не будет. Багов будет столько же, только ловиться будут быстрее. Как правило, у какого-то значения есть мало источников, зато много потребителей. (Типа поле инициализируется одним из трех конструкторов, а потом читается в полусотне методов). Внедрение non-null позволит раньше отловить передачу некорректного значения.

M>Не очень удобно, IMHO, так как не-null можно рассматривать как один из constraint-ов данных. Могут быть и другие условия, вроде interned объектов (которые можно сравнивать на равенство по ссылке, а не по значению). Если на одину ссылку наложить несколько условий — то не понятно в каком порядке их "оборачивать" в эти врапперы.
Это верно. Правильным ответом, безусловно, является паттерн-матчинг. Но реально NPE — это 98% констреинтов.

Здравствуйте, Sinclair, Вы писали:

S>Так Влад и предлагает ввести пустой объект "соседнего" класса.

Не, паттерн null object проблемы не решает. Ну будет вместо NPE исключение при обращении к полям null object — только косвенность увеличится. Влад другое предлагает — ввести хотя бы частичный контроль за null на стадии компиляции, а не в рантайме.

Sinclair wrote:
> Нет, не будет. Багов будет столько же, только ловиться будут быстрее.
> Как правило, у какого-то значения есть мало источников, зато много
> потребителей. (Типа поле инициализируется одним из трех конструкторов, а
> потом читается в полусотне методов). Внедрение non-null позволит раньше
> отловить передачу некорректного значения.
В Java в IDEA есть подобная фича — можно ставить аннотации @NotNull на
параметры методов, поля класса и т.п. Инспектор будет автоматически
проверять это при компиляции на этапе инспекции.

Использую в проекте везде. Я бы не сказал, что мне это сильно помогает —
но какое-то число ошибок сразу при редактировании отлавливается.

Здравствуйте, Cyberax, Вы писали:

C>В Java в IDEA есть подобная фича — можно ставить аннотации @NotNull на
C>параметры методов, поля класса и т.п. Инспектор будет автоматически
C>проверять это при компиляции на этапе инспекции.

В решарпере тоже.

C>Использую в проекте везде. Я бы не сказал, что мне это сильно помогает —
C>но какое-то число ошибок сразу при редактировании отлавливается.

А это потому что оно не обязательно, и стандартная библиотека не аннотирована.

Здравствуйте, AndrewVK, Вы писали:

AVK>В решарпере тоже.
AVK>А это потому что ... стандартная библиотека не аннотирована.

Скоро это изменится.
Молчу, молчу... Ребята скоро сами расскажут.

Здравствуйте, VladD2, Вы писали:

E>>>>В одной раз забабахали утверждения, что managed-языки и ФП -- рулез.

IT>>>Детский сад, штаны на лямках. Я ведь я тебя считал почти взрослым человеком.

E>>Я просто очень большой ребенок А любимые игрушки -- велосипеды

VD>Это было не странное если не одно "но". Нормальные дети любят кататься на велосипедах, а не зацикливаются на их изобретении.

А кто здесь настаивал на нормальности?

PS. Смотрю тебе так же захотелось покидаться дерьмом в вентилятор.

Здравствуйте, VladD2, Вы писали:

VD>2. Ввести в систему типов аналог option[T] (нулабл-типы из дотнета не подходят, так как они применимы исключительно для вэйлью-типов).
Они не решают эту проблему и для value types — меня компилятор не обязывает проверять есть ли значение в обёртке.
Это подходит только для систем типов с алгебраическими типами данных.

Здравствуйте, AndrewVK, Вы писали:
AVK>Не, паттерн null object проблемы не решает. Ну будет вместо NPE исключение при обращении к полям null object — только косвенность увеличится.
Это если не пользоваться non-null object
Просто non-null выбросит NPE не при использовании, как сейчас, а при присваивании.
AVK>Влад другое предлагает — ввести хотя бы частичный контроль за null на стадии компиляции, а не в рантайме.
Частичный — да. На стадии компиляции просто будет принудительно проверяться наличие проверок в оговоренных разработчиком местах.

Здравствуйте, mkizub, Вы писали:

M>Нереально. То есть можно "как правило" отказаться (введя "пустой объект" данного класса, скажем пустую строку для строк), за исключением небольшого числа случаев (0 тоже долго не считали числом, но потом решили, что уж слишком удобное понятие).
M>Но это будет не сильно большим выходом, ошибки NPE сейчас — чаще всего замаскированная другая ошибка. В каком-то смысле NPE — это автоматически расставляемые компилятором/VM ассерты. Не будет NPE — будут ещё более трудно уловимые баги.

Это может выглядело бы нереально, если бы не было реализовано в целом ряде языков (см. ML, Хаскель, к примеру).

M>Не очень удобно, IMHO, так как не-null можно рассматривать как один из constraint-ов данных. Могут быть и другие условия, вроде interned объектов (которые можно сравнивать на равенство по ссылке, а не по значению). Если на одину ссылку наложить несколько условий — то не понятно в каком порядке их "оборачивать" в эти врапперы.

Это какая-то наукооразная ахинея, уж извини за грубость. Я уже сказал, что и где читать. Там все описано очень подробно. Давай не перемалывать воду в ступе. ОК?

VD>>3. Заставить программиста явно указывать, что ему нужен option[T]-тип, в тех местах где программист ранее передавал null в качестве некоторого сигнала.

M>И чтоб это было опционально. То есть программист мог включать для отдельных модулей проверку на NPE, и эта ошибка тогда будет проверяться на стадии компиляции.

К сожалению, реализовать переключаемую систему типов скорее всего будет очень сложн (ведь модули должны работать совместно). По сему проще сделать систему типов в кторой просто не будет места для null. Собственно если бы это не было так, то что-то подобное уже сделали бы.

VD>>4. Заставить компилятор требовать инициализации всех перменных не null-значениями.

M>Что невозможно, по причинам (1). Или тогда надо делать это эквивалентным (2).

В корне не верно. Именно наличие пунктов 1 и 2 повзоялет осуществить пункт 3. Компилятор должен производить анализ потока вычисления и требовать, чтобы любое поле любого объекта было инициализированно каким-то не null-значением. option[T] не является null-ом, так что все ОК.

Можно даже сказать, что п. 3 и п. ё1 — это следствие одного и того же решения. Просто п. 3 — это скорее реализация, а не требование.


VD>>Как вариант — внедрить в жизнь технологии аля Spec#. Но пока что до этого далеко.

M>Надо почитать что у них там...

Давно бы занялся. Уверяю тебя как минимум 90% вопросов сами собой исчезнут.