Еще пример сильной статической типизации - Swift, там доходит даже до абсурда когда нельзя, например, к int16 прибавить int8 без преобразования типов в один.
Я бы добавил, что: 1) Статическая/динамическая типизация - это скорее дискретная, бинарная величина. Язык либо динамический, либо статический. А вот сильная/слабая - это некоторая условность, скорее непрерывная величина (язык может быть более или менее сильно типизированным). 2) К слабой типизации я бы отнёс не только неявные преобразования типов, но и лёгкие лайфхаки с помощью явных преобразований, типа A *a = new A(); B *b = (B*)(void*)a; // Любой указатель в любой
Насколько понял, в C++ переопределения встроенных типов уже относят язык к слабой типизации из-за возможного неявного преобразования. Но вот насчет кастования экземпляров классов, по-сути вы, как их разработчик, сами должны явно определить оператор приведения. Т.е. в этом случае язык можно отнести к больше сильной типизации. Явным примером будет тот же OpenCV. Но с позиции пользователя таких библиотек язык будет больше тяготеть к слабой типизации? Ведь неявное преобразование в таком случае возможно (вы интуитивно предполагаете, что кастование возможно, и оно само по себе происходит)
@@АлинаЛебедева-м5ь Шарп может схитрить и сохранить тип в рантайме. В плюсах типы вычисляются на этапе компиляции, что благоприятно сказывается на производительности. Мощнее всех типизация у Haskell и Rust
@@8Johnny8Catsvill8 Нет, шарп на самом деле очень очень много выводит типы именно в компайл тайме. Если в плюсах при использовании лямбд нужно обязательно указывать типы, то в шарпе нет. У оператора new тип также чаще всего необязательно указывать
@@АлинаЛебедева-м5ь кто вам сказал, что в лямбдах надо указывать тип? Разве что в C++11 были сильные ограничения, которые исправили в C++14. И как я сказал, уже в C++17 вывод типов был серьёзно прокачан и стало возможным не указывать тип шаблона, например. В C++20 эту традицию продолжили и можно не писать template над функцией, а просто auto вместо типа, и наоборот указывать в лямбдах template, если потребуется. А с приходом концептов вообще заживём и будем видеть понятный и красивый вывод ошибок, а не то мракобесие на 10 тыс. строк из-за того что ты просто передал число вместо строки. И там вообще много всякого по мелочи. Тем не менее при чём тут C# и как он влияет на C++? Одно другому не мешает
Когда я был молодым и горячим мне больше нравились языки с динамической типизацией. Поработав 5 лет, понял, сильная и статическая это минимум проблем и максимум удобства
Уже было собрался писать комментарий о том, что не всегда в статически типизируемых языках нужно указывать типы, но в конце видео это раскрыто, спасибо! Расскажите пожалуйста, если Вам интересна данная тема, как работают подобные системы вывода типов, об алгоритме Хиндли-Милнера и других (если они существуют)
6:40 Soer я не совсем понял что значит "вообще не думая о семантике", ты обязан явно указать преобразование при полном не согласовании типов, иначе ни как, к примеру: int* x = new int(6513249); char* abc_str = reinterpret_cast(x); // "abc" стиль преобразования с++. или char* abc_str = (char*)x; // "abc" стиль преобразования с. PS: не явное преобразование floating point в integer с потерей дробной части не в счёт :D В с++17 такие проблемы решаются с помощью фигурных скобок. 9:44 Это шаблоны с++ тип вычисляется во время компиляции, в с# наверное также. Lisp попадает под слабо динамическую типизацию :)
Прошло уже 7 месяцев и я всё не могу успокоиться :)) В видео по ссылке ниже на 2:10 лектор все мои мысли высказал на счёт почему С++ является всё же строго типизированный язык. ruclips.net/video/VRZybVWXv3Y/видео.html Понятно что каждый по своему может понимать что такое Сильная/Слабая типизация, так к примеру в Haskell всё на столько строго что: (1 :: Float) + (2 :: Double) Couldn't match expected type ‘Float’ with actual type ‘Double’ In the second argument of ‘(+)’, namely ‘(2 :: Double)’ In the expression: (1 :: Float) + (2 :: Double)
Например можно сделать класс комплексных чисел, определить оператор +, а потом сделать конструктор, принимающий на вход ровно один double (для действительной части). После чего будет корректно компилироваться и исполняться код типа Complex a = new Complex(0, 0); Complex b = a + 1; Компилятор будет неистово приводить типы, пока не догадается, что имелось в виду Complex b = a + new Complex((double) 1.0);
Благодарю за видео! Правда, мне не хватило про строгую типизацию. Она изначально появилась из теории, что типизировав всё, программисты избавятся от багов, поскольку будет невозможно выполнить недопустимую операцию. Этой теории уже лет 70, понемногу к ней подходят Идрис и Хаскель, но всё еще очень далеко. И поэтому же частичная типизация в Питоне станет интересным экспериментом - это в корне противоречит изначальной теории типов
Как JS, но построже типизация. Честно говоря, сильно/слабо типизированный это не дихотомия, а спектр. Я давно на TS не писал, но у меня осталось впечатление строгой типизации.
@@garorobe в тайпскрипте статическая типизация, тип указывается при объявлении переменной и емнип слабо типизирован, все так же можно складывать число и строку. Правда все это довольно условно, учитывая any
По факту, когда в питоне ты умножаешь строку на чисто, то это по сути вызов функции строки( str().__mul__(number: int)). Те же строки у тебя не выйдет умножить, как и "умножить" строку на float. По сути это аналог перегруженой операции в С++
И например, у тебя не выйдет сделать int(3).__mul__(3.0), сначала пайтон приведет тип и только после умножит: int(3).__float__().__mul__(3.0). И фишка в том, что если в объекте нет такого метода, то будет ошибка. То есть все достаточно строго.
@@eugenekolyvoshko8809 если это не автоматический кастинг, то что? было 3 * 'z' стало 'zzz'. На входе два типа, на выходе 1. Как этот результат достигнут по моему особого значения не имеет, разве нет?
Да не, ну всё понятно - не сложная тема так-то. Вообще не понимаю, чего столько шума вокруг этого - ну не складывай тёплое с мягким - будь бдителен - и всё будет ок.
Ну... выглядит странно, что автор рассуждает о типах, даже не дав определение того, что такое тип. Особенно в свете того, что существует как минимум два разных определения :) Во-первых, тип можно определить как информацию времени компиляции программы, которая служит для того, чтобы запретить выполнение некоторых нежелательных действий, таких как присваивание значений, которые не несут смысла, обращение по нулевому указателю, выход за пределы массива, race conditions, для доказательства каких-то свойств, и т. д. и т. п. и др. и пр. В принципе, если брать классические книги по теории типов (того же Пирса), то там используются именно такое определение. Во-вторых, тип может быть часть значения, которая доступна на стадии выполнения. Такая ситуация наблюдается как раз в Python, JS. Вообще, с точки зрения первого определения, в Python существует один единственный тип данных `PyObject *`. И с этой точки зрения Python можно рассматривать как пример сильной типизации (раз тип только один, то никакой ошибки типов быть не может). Если брать всякий ширпотреб типа Java, C#, да и вообще Simula-like ООП, то там тип это некоторая помесь этих двух определений, обычно для класса всё-таки хранится указатель на VMT по которому можно узнать какого мы типа. Ну и... как-то причудливо выглядят попытки играться словами совместимые/несовместимые типы в случае сильной/слабой типизации, такое себе жоглирование новыми терминами без строгого опреления. Например, в Си мы считаем типы несовместимыми, а в Java совместимыми, оставляя себе лазейку куда можно поместить тот или иной язык исходя из маркетинговых задач. Как по мне тут речь идёт больше о другом свойстве языков: безопасность/не безопасность, которое показывает, как сложно получить в языке UB (undefined behaviour) и тут типы как-то ортогональны, потому как вот просто пример UB, который сложно привязать к типам. ``` std::vector a = { 1, 2, 3 }; auto ptr = a.begin(); a.push_back(4); *ptr = 0; ``` Более строго оценивать сильную/слабую типизацию как раз с точки зрения того, сколько совместимых типов есть в языке. Если брать упоминавшиеся языки ML группы, то там совместимых типов как раз нуль, вот она сильная типизация во всей красе. Всё остальное слабее. Опять же, возможность явного приведения типа, ИМХО, не есть какая-либо проблема. Языки сильной типизации не запрещают существование функций, которые берут значения одного типа и возвращают значение другого типа, и явное преобразование типа может легко быть рассмотрено как вызов соответствующей функции.
как же бесит неочевидность терминологии в программировании. "Сильная динамическая явная типизация" - такое нормальный человек не способен понять без гугла и такой-то матери )
Запятые расставьте после сильная и динамическая и будет намного понятней на самом деле. Плюс слово "сильная" типизация, как раз значительно хуже отражает суть. Намного лучше и понятней когда вместо этого термина используется "строгая" типизация. Не сказал бы, что с терминологией в программировании что-то не так.
@@mrWWarlock даже гуманитарии говорят на своем идиотском пронизанном ненужными терминами языке там, где можно было бы говорить человеческим. Ничего хорошего в этом нет. Бессмысленная когнитивная нагрузка ради гордости за свои знания
По факту сильная типизация оказывается слабой, т.к. при возникновении ситуации, где нужно разобраться с несовместимыми типами, она поднимает белый флаг и выбрасывает ошибку. Слабая же типизация разруливает любую непонятную ситуацию как Джейсон Стетхем: молча и результативно.
Молча и результативно. Правда иногда получается херня, и ты так просто не узнаешь где она произошла. И добро пожаловать в удивительный мир многочасового дебаггинга
На самом деле сама идея типизации состоит в том, чтобы на этапе компиляции запретить разное нежелательное поведение, типа race conditions, обращение по нулевому указателю, выход за пределы массивов, чтение из файла до его открытия, всякие переполнения, неожиданные результаты и т. д. и т. п. и др. и пр. Поэтому считается общепринятым, что чем более сильная система, тем больше нежелательных действия запрещено, тем сильнее система типов. Иначе мы приходим к неожиданному результату, что ассемблер обладает самой сильной системой типой, ибо разруливает любую непонятную ситуацию без ошибок :)
@@jmik4956 у меня была ошибка в универе при попытке засунуть в регистр меньшего размера что-то большее и в итоге я получил ошибку. Чем это не проверка типа?
@@andbog96 это что-то отличается чем-то кроме размера? Нет это такое же число но другой разрядности. Типизация подразумевает что объект (не только ООП) без доп модификаций может быть интерпретирован только одним способом, в ООП языках - большинство вещей указатели (и вроде как должны легко переводиться друг в друга. Но компилятор джавы тебе такое провернуть не даст ибо строгая типизация
@@jmik4956 суть типизации в том чтобы запретить определенные действия и вернуть ошибку. В асм если в однобайтовый регистр пытаться записать 2х байтовую инфу, как раз будет ошибка. Пусть это не называется на прямую типизацией, но по сути это как раз ей и является. То есть у нас тип это размер в байтах. Это всё имхо, уже не так хорошо помню то что было в универе.
Это были полезные 12 минут, действительно стало понятнее. Спасибо.
Оо... Думаю многим будет полезно, так как многие путают строгую и статическую типизацию
Довольно продолжительное время были проблемы с потенцией, но после просмотра соера стоит как кол. Спасибо за видео.
@@кавказ-в4з чел, тебе лучше в тему юмора не влезать. У меня тоже встал.
@@casualmma Надеюсь вопрос, и не на автора видео?
Супер! Всё чётко и понятно. Спасибо❤
Насколько простое и полезное видео, что аж гармоны бурлят
Разбери рест. В чём его преимущество над другими парадигмами. Например Rest vs Soap. Хотя Soap протокол, но все равно интересно сравнить
На "Вы" надо обращаться!
@@purplep3466 не надо, в Европе на ты обращаются
@@mohnatyi_hleb с русскими дедами надо на "Вы" :D
@@purplep3466 да ладно не такой уж и дед, но выражается уже душновато пришлось включить ускорение
лучший теоретический канал о программировании и инженерном мышлении, имхо
де-факто
Понял все со второго раза) Спасибо за видео. Только начиная программировать, хорошое видео.
Спасибо. Простая, но очень полезная информация 👍
Благодарю!! 👍🏻 Очень доступно и понятно!! Рад, что наткнулся на Ваш канал!! 😊
Еще пример сильной статической типизации - Swift, там доходит даже до абсурда когда нельзя, например, к int16 прибавить int8 без преобразования типов в один.
Аналогичная ситуация и в Go
Добавьте к списку Rust.
Просто и понятно о базовых и необходимых понятиях 😎👍
Молодчик, хорошо объяснил! Спасибо.
стало понятнее
намного
спасибо!
Я бы добавил, что:
1) Статическая/динамическая типизация - это скорее дискретная, бинарная величина. Язык либо динамический, либо статический. А вот сильная/слабая - это некоторая условность, скорее непрерывная величина (язык может быть более или менее сильно типизированным).
2) К слабой типизации я бы отнёс не только неявные преобразования типов, но и лёгкие лайфхаки с помощью явных преобразований, типа
A *a = new A();
B *b = (B*)(void*)a; // Любой указатель в любой
Соер, спасибо за выпуск, мне стало более понятно по типизации. Хорошего дня!
корректоно ли утвеждение: все компилируемые - стат.типизированные, а все интерпретируемые - дин.типизированные?
Спасибо за такое подробное видео! Очень полезно!
Насколько понял, в C++ переопределения встроенных типов уже относят язык к слабой типизации из-за возможного неявного преобразования.
Но вот насчет кастования экземпляров классов, по-сути вы, как их разработчик, сами должны явно определить оператор приведения. Т.е. в этом случае язык можно отнести к больше сильной типизации. Явным примером будет тот же OpenCV. Но с позиции пользователя таких библиотек язык будет больше тяготеть к слабой типизации? Ведь неявное преобразование в таком случае возможно (вы интуитивно предполагаете, что кастование возможно, и оно само по себе происходит)
Замечательный разбор, даже я понял)
C++ тоже очень продвинулся в выводе типов на этапе компиляции
Могу сказать, шарп в этом намного сильнее продвинулся
@@АлинаЛебедева-м5ь Шарп может схитрить и сохранить тип в рантайме. В плюсах типы вычисляются на этапе компиляции, что благоприятно сказывается на производительности. Мощнее всех типизация у Haskell и Rust
@@8Johnny8Catsvill8 Нет, шарп на самом деле очень очень много выводит типы именно в компайл тайме. Если в плюсах при использовании лямбд нужно обязательно указывать типы, то в шарпе нет. У оператора new тип также чаще всего необязательно указывать
@@АлинаЛебедева-м5ь кто вам сказал, что в лямбдах надо указывать тип? Разве что в C++11 были сильные ограничения, которые исправили в C++14. И как я сказал, уже в C++17 вывод типов был серьёзно прокачан и стало возможным не указывать тип шаблона, например. В C++20 эту традицию продолжили и можно не писать template над функцией, а просто auto вместо типа, и наоборот указывать в лямбдах template, если потребуется. А с приходом концептов вообще заживём и будем видеть понятный и красивый вывод ошибок, а не то мракобесие на 10 тыс. строк из-за того что ты просто передал число вместо строки. И там вообще много всякого по мелочи. Тем не менее при чём тут C# и как он влияет на C++? Одно другому не мешает
Супер понятно. Спасибо
Ёмко, четко. Лайкос.
Респект за корректное упоминание ML.
Спасибо за хорошую тему
Ещё раз спрошу уже под этим видео - скажи пожалуйста что у тебя за планшет, на котором ты рисуешь?
Обожаю, когда в C++ решил поработать с int32 и uint32 в одном и том же месте 🤩😍
Применяйте auto))
Комментарии продвигают видео, пишите комментарии!
Когда я был молодым и горячим мне больше нравились языки с динамической типизацией. Поработав 5 лет, понял, сильная и статическая это минимум проблем и максимум удобства
Очень познавательно, спасибо :)
Очень интересует вопрос- как и где в интернете можно пройти обучение по программированию ??
@@TomasuTom везде то оно везде. Обучиться- это одно, а ещё понять предоставляемый к обучению материал и вникнуть в суть, это уже другое.....
@@TomasuTom похоже на поиск в самом себе- очень долго, но эффективно )
@@TomasuTom Пытаюсь сделать канал с объяснениями, что такое и как работает. Выйдет/не выйдет - не знаю, подписываться/не подписываться - решать вам.
Толково, спасибо
Уже было собрался писать комментарий о том, что не всегда в статически типизируемых языках нужно указывать типы, но в конце видео это раскрыто, спасибо! Расскажите пожалуйста, если Вам интересна данная тема, как работают подобные системы вывода типов, об алгоритме Хиндли-Милнера и других (если они существуют)
Спасибо, Соер умеет копать!
Спасибо, очень интересно.
Это политические координаты с ЯП?
большое спасибо за видео!
Спасибо! Доходчиво.
Я который всю жизнь жил в 2д статическо-динамическом мире, а потом понял что есть ещё измерения: 🗿
Благодарю!
Странно, что мало людей посмотрело
Спасибо, было полезно
Соер, на каком кресле ты сидишь?
Это обычное офисное кресло, как сетчатое только натянуто кожей. У меня такое дома.
Большое спасибо
6:40 Soer я не совсем понял что значит "вообще не думая о семантике", ты обязан явно указать преобразование при полном не согласовании типов, иначе ни как, к примеру:
int* x = new int(6513249);
char* abc_str = reinterpret_cast(x); // "abc" стиль преобразования с++.
или
char* abc_str = (char*)x; // "abc" стиль преобразования с.
PS: не явное преобразование floating point в integer с потерей дробной части не в счёт :D В с++17 такие проблемы решаются с помощью фигурных скобок.
9:44 Это шаблоны с++ тип вычисляется во время компиляции, в с# наверное также.
Lisp попадает под слабо динамическую типизацию :)
Бывают моменты, когда происходит автоматическое преобразование, обычно в конструкторах
@@VladykaVladykov Да это порой не приятно бывает:) конструкторы с одним параметром всегда explicit делать нужно.
Имелось ввиду, что c++ слабый из-за кучи неявных преобразований: неявные вызовы конструкторов, если нет функции с нужными аргументами
Прошло уже 7 месяцев и я всё не могу успокоиться :))
В видео по ссылке ниже на 2:10 лектор все мои мысли высказал на счёт почему С++ является всё же строго типизированный язык.
ruclips.net/video/VRZybVWXv3Y/видео.html
Понятно что каждый по своему может понимать что такое Сильная/Слабая типизация, так к примеру в Haskell всё на столько строго что:
(1 :: Float) + (2 :: Double)
Couldn't match expected type ‘Float’ with actual type ‘Double’
In the second argument of ‘(+)’, namely ‘(2 :: Double)’
In the expression: (1 :: Float) + (2 :: Double)
Полезно, спасибо
То, что плюсы относятся к слабо типизированным, это неожиданное открытие. Ведь действительно можно...
Например можно сделать класс комплексных чисел, определить оператор +, а потом сделать конструктор, принимающий на вход ровно один double (для действительной части). После чего будет корректно компилироваться и исполняться код типа
Complex a = new Complex(0, 0);
Complex b = a + 1;
Компилятор будет неистово приводить типы, пока не догадается, что имелось в виду
Complex b = a + new Complex((double) 1.0);
Спасибо
имба видео
Благодарю за видео! Правда, мне не хватило про строгую типизацию. Она изначально появилась из теории, что типизировав всё, программисты избавятся от багов, поскольку будет невозможно выполнить недопустимую операцию. Этой теории уже лет 70, понемногу к ней подходят Идрис и Хаскель, но всё еще очень далеко.
И поэтому же частичная типизация в Питоне станет интересным экспериментом - это в корне противоречит изначальной теории типов
Жаль, что не затронута тема опциональной статической типизации.
Это где такое есть? В python?
@@mohnatyi_hleb typescript, php, python, elixir
К какому виду относится TypeScript, и какие у него нюансы?
Как JS, но построже типизация. Честно говоря, сильно/слабо типизированный это не дихотомия, а спектр. Я давно на TS не писал, но у меня осталось впечатление строгой типизации.
TypeScript статический с сильной типизацией, но в итоге он естественно компилируется в JavaScript.
Про нюансы вопрос не совсем понял
@@garorobe в тайпскрипте статическая типизация, тип указывается при объявлении переменной и емнип слабо типизирован, все так же можно складывать число и строку. Правда все это довольно условно, учитывая any
Я вот на питоне пишу, так то сильная типизация. Но можно строки на целые числа умножать. Формально это какой то привет из мира слабой типизации :).
По факту, когда в питоне ты умножаешь строку на чисто, то это по сути вызов функции строки( str().__mul__(number: int)). Те же строки у тебя не выйдет умножить, как и "умножить" строку на float. По сути это аналог перегруженой операции в С++
И например, у тебя не выйдет сделать int(3).__mul__(3.0), сначала пайтон приведет тип и только после умножит: int(3).__float__().__mul__(3.0). И фишка в том, что если в объекте нет такого метода, то будет ошибка. То есть все достаточно строго.
@@eugenekolyvoshko8809 ну такое себе объяснение. Автоматический кастинг происходит? Происходит.
@@Игорь-ч6ф3и при умножении строки на число никакого кастинга автоматического не будет.
@@eugenekolyvoshko8809 если это не автоматический кастинг, то что? было 3 * 'z' стало 'zzz'. На входе два типа, на выходе 1. Как этот результат достигнут по моему особого значения не имеет, разве нет?
график с языками - топ
Годнота
Круто!
Стоит ли работающему свитчеру получать образование заочно?
Забавно)
@@fallenangel1395 ага, как раз вышел ответ на мой вопрос)
Разница между утиной и структурной не раскрыта.
Да не, ну всё понятно - не сложная тема так-то.
Вообще не понимаю, чего столько шума вокруг этого - ну не складывай тёплое с мягким - будь бдителен - и всё будет ок.
Блюра многоооо!
👍👍👍
спасибо
но всё равно слодно для понимания (я совершенно не разбираюсь в программировании)
Типизация и система типов - это две большие разницы.
Ну... выглядит странно, что автор рассуждает о типах, даже не дав определение того, что такое тип. Особенно в свете того, что существует как минимум два разных определения :)
Во-первых, тип можно определить как информацию времени компиляции программы, которая служит для того, чтобы запретить выполнение некоторых нежелательных действий, таких как присваивание значений, которые не несут смысла, обращение по нулевому указателю, выход за пределы массива, race conditions, для доказательства каких-то свойств, и т. д. и т. п. и др. и пр. В принципе, если брать классические книги по теории типов (того же Пирса), то там используются именно такое определение.
Во-вторых, тип может быть часть значения, которая доступна на стадии выполнения. Такая ситуация наблюдается как раз в Python, JS. Вообще, с точки зрения первого определения, в Python существует один единственный тип данных `PyObject *`. И с этой точки зрения Python можно рассматривать как пример сильной типизации (раз тип только один, то никакой ошибки типов быть не может). Если брать всякий ширпотреб типа Java, C#, да и вообще Simula-like ООП, то там тип это некоторая помесь этих двух определений, обычно для класса всё-таки хранится указатель на VMT по которому можно узнать какого мы типа.
Ну и... как-то причудливо выглядят попытки играться словами совместимые/несовместимые типы в случае сильной/слабой типизации, такое себе жоглирование новыми терминами без строгого опреления. Например, в Си мы считаем типы несовместимыми, а в Java совместимыми, оставляя себе лазейку куда можно поместить тот или иной язык исходя из маркетинговых задач. Как по мне тут речь идёт больше о другом свойстве языков: безопасность/не безопасность, которое показывает, как сложно получить в языке UB (undefined behaviour) и тут типы как-то ортогональны, потому как вот просто пример UB, который сложно привязать к типам.
```
std::vector a = { 1, 2, 3 };
auto ptr = a.begin();
a.push_back(4);
*ptr = 0;
```
Более строго оценивать сильную/слабую типизацию как раз с точки зрения того, сколько совместимых типов есть в языке. Если брать упоминавшиеся языки ML группы, то там совместимых типов как раз нуль, вот она сильная типизация во всей красе. Всё остальное слабее. Опять же, возможность явного приведения типа, ИМХО, не есть какая-либо проблема. Языки сильной типизации не запрещают существование функций, которые берут значения одного типа и возвращают значение другого типа, и явное преобразование типа может легко быть рассмотрено как вызов соответствующей функции.
Мда... Кто то умник что сказал что "JavaScript" не типизирован, когда там есть такая штука как "typeof"
C#?
там вообще солянка: и dynamic, и object..
Строгая и сильная
@@purplep3466 чем тебе object не нравится? Всё по науке все классы от object
как же бесит неочевидность терминологии в программировании. "Сильная динамическая явная типизация" - такое нормальный человек не способен понять без гугла и такой-то матери )
Запятые расставьте после сильная и динамическая и будет намного понятней на самом деле. Плюс слово "сильная" типизация, как раз значительно хуже отражает суть. Намного лучше и понятней когда вместо этого термина используется "строгая" типизация. Не сказал бы, что с терминологией в программировании что-то не так.
@@user-dn6vv9qd4w на сколько я знаю русский язык, запятой здесь не должно быть, это неоднородные определения
@@user-dn6vv9qd4w палку эту засунь куда подальше, потом про запятые спрашивать будешь
Дружище, слышал бы ты что говорят медики и атомные физики.
@@mrWWarlock даже гуманитарии говорят на своем идиотском пронизанном ненужными терминами языке там, где можно было бы говорить человеческим. Ничего хорошего в этом нет. Бессмысленная когнитивная нагрузка ради гордости за свои знания
Послушай, что тебе дедушка говорит
А есть продвинутые языки, которые могут как в сильную, так и в слабую типизации, например, PHP.
По факту сильная типизация оказывается слабой, т.к. при возникновении ситуации, где нужно разобраться с несовместимыми типами, она поднимает белый флаг и выбрасывает ошибку.
Слабая же типизация разруливает любую непонятную ситуацию как Джейсон Стетхем: молча и результативно.
Молча и результативно. Правда иногда получается херня, и ты так просто не узнаешь где она произошла. И добро пожаловать в удивительный мир многочасового дебаггинга
@@Евгений-п1л1ъ стоит отметить, что Стэтхем оставляет после себя хаос и разрушения и головную боль для мэрии и коммунальных служб
На самом деле сама идея типизации состоит в том, чтобы на этапе компиляции запретить разное нежелательное поведение, типа race conditions, обращение по нулевому указателю, выход за пределы массивов, чтение из файла до его открытия, всякие переполнения, неожиданные результаты и т. д. и т. п. и др. и пр. Поэтому считается общепринятым, что чем более сильная система, тем больше нежелательных действия запрещено, тем сильнее система типов. Иначе мы приходим к неожиданному результату, что ассемблер обладает самой сильной системой типой, ибо разруливает любую непонятную ситуацию без ошибок :)
Неправильно. В python слабая типизация. Язык с сильной типизацией не позволит складывать float и int.
шарп - язык с строгой типизацией, но позволяет такое делать
@@ИгорьЖиров-м9ъ значит недостаточно строгой
У асм есть типы, это размеры регистров в байтах например
Но типов как таковых - нет ты одну и туже облать памяти интерпретируешь ее как хочешь
@@jmik4956 у меня была ошибка в универе при попытке засунуть в регистр меньшего размера что-то большее и в итоге я получил ошибку. Чем это не проверка типа?
@@andbog96 тем, что ты пытался засунуть "что-то")
@@andbog96 это что-то отличается чем-то кроме размера? Нет это такое же число но другой разрядности. Типизация подразумевает что объект (не только ООП) без доп модификаций может быть интерпретирован только одним способом, в ООП языках - большинство вещей указатели (и вроде как должны легко переводиться друг в друга. Но компилятор джавы тебе такое провернуть не даст ибо строгая типизация
@@jmik4956 суть типизации в том чтобы запретить определенные действия и вернуть ошибку. В асм если в однобайтовый регистр пытаться записать 2х байтовую инфу, как раз будет ошибка. Пусть это не называется на прямую типизацией, но по сути это как раз ей и является. То есть у нас тип это размер в байтах. Это всё имхо, уже не так хорошо помню то что было в универе.
BrainFuck не типизирован
Бейсик нетипизированный
Какой-то мутный тип...
За ролик большое спасибо, но в начале ролика, очень прошу не надо так ручкой делать.
@@diasnagurbek программисты нежные.
Почему у тебя левый глаз открыт шире чем правый?
Тебе подмигивают, у меня все нормально.
Левый глаз со слабой динамической типизацией, а правый со строгой статической. Имхо, очевидно же.
Я думала обойдётся без такого вопроса в комментах, ан нет, нашёлся, таки, один)
@@onnikkaona8564 спасибо, хоть кто-то меня понимает
Спасибо за это видео
спасибо