напоминает динамическую или слабую типизацию. Сейчас флоат а потом бац - интежер.

По факту является обратным - сильной статической типизацией

понял, спасибо

если бы вы видили в какой говнокод превращается работа со значениями таких типов на практике - развесистый паттернматчинг, ужасы с отбивкой пробелами при рефакториге, десяток враперов для простого инта и т.д. -, вы бы не благодарили

на вики пишут, что это Дизъюнктное объединение, то есть общая часть отбрасывается и остается то, чего нет в первой + то , чего нет во второй?

По факту является обратным - сильной статической типизацией

суть понял, спасибо. Но зачем тогда нужна такая сильная статическая, когда логичнее отдельно пользоваться флоатом и интежером например?

на вики пишут, что это Дизъюнктное объединение, то есть общая часть отбрасывается и остается то, чего нет в первой + то , чего нет во второй?

Значение типа суммы - это всегда значение типа + метка типа, от этого дизъюнктивное объединение, ибо количество значений для объединения типов A и B всегда равно сумме количества значений обоих типов.

суть понял, спасибо. Но зачем тогда нужна такая сильная статическая, когда логичнее отдельно пользоваться флоатом и интежером например?

Бывают ситуации когда нужна возможность хранить где-то значение либо одного типа, либо другого. Например, типичная ситуация - обработка ошибок.

конечные автоматы - тоже хороший пример

Ещё один канонический пример - AST

Бывают ситуации когда нужна возможность хранить где-то значение либо одного типа, либо другого. Например, типичная ситуация - обработка ошибок.

ты еще красную книгу тут посоветуй почитать)

конечные автоматы - тоже хороший пример

Честно говоря, для меня это похоже на теорию, которая применима нигде. В том смысле, что подходящих случаев ноль.

Честно говоря, для меня это похоже на теорию, которая применима нигде. В том смысле, что подходящих случаев ноль.

Это типичное "я не знаю того, что я не знаю". Пока вы с этим не сталкивались и особо то и не знаете что это такое, поэтому и не понимаете зачем это нужно.

Честно говоря, для меня это похоже на теорию, которая применима нигде. В том смысле, что подходящих случаев ноль.

в смысле ? стейт-машины никогда не писали ?

ты еще красную книгу тут посоветуй почитать)

Что за книгу?

Это типичное "я не знаю того, что я не знаю". Пока вы с этим не сталкивались и особо то и не знаете что это такое, поэтому и не понимаете зачем это нужно.

совершенно верно.

Что за книгу?

ммм, проехали. я думал вы из скалоидов.

Честно говоря, для меня это похоже на теорию, которая применима нигде. В том смысле, что подходящих случаев ноль.

подходящие случаи бывают на самом деле. они относятся матану и теории категорий на уровне докторской диссертации. Ни один из мальчиков, с упоением рассказывающих про ФП, об этом даже не догадывется)

подходящие случаи бывают на самом деле. они относятся матану и теории категорий на уровне докторской диссертации. Ни один из мальчиков, с упоением рассказывающих про ФП, об этом даже не догадывется)

+

обычные проверки в сишном стиле вкупе с операторами if break return читаются на много проще чем паттерн матчинг типов сум. ФП в принципе не может ничего упростить - строго только усложнить. И для задач его применяют соответствующих

подходящие случаи бывают на самом деле. они относятся матану и теории категорий на уровне докторской диссертации. Ни один из мальчиков, с упоением рассказывающих про ФП, об этом даже не догадывется)

Вы как АСТ сделано в го видели? Вот там типичные костыли для эмуляции енамов .

нет, не видел. А что не так?

обычные проверки в сишном стиле вкупе с операторами if break return читаются на много проще чем паттерн матчинг типов сум. ФП в принципе не может ничего упростить - строго только усложнить. И для задач его применяют соответствующих

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

Ну так посмотрите. Там объявление интерфейса с приватным методом, который ничего не делает. Потом на нужных типах эти методы «реализуют». И все для того чтобы в качестве аргумента можно было передать только конечное множество типов. А внутри касты интерфейсов к типам.

Ну так посмотрите. Там объявление интерфейса с приватным методом, который ничего не делает. Потом на нужных типах эти методы «реализуют». И все для того чтобы в качестве аргумента можно было передать только конечное множество типов. А внутри касты интерфейсов к типам.

Читаемость уровня го

Даже в сишке это делается не так костыльно

А в сочетании с утиной типизацией вообще невозможно найти все типы которые можно передать внутрь.

в смысле ? стейт-машины никогда не писали ?

ну, разве что свичами и иф-зенами.

Читаемость уровня го

уровня /go 😂

Ну так посмотрите. Там объявление интерфейса с приватным методом, который ничего не делает. Потом на нужных типах эти методы «реализуют». И все для того чтобы в качестве аргумента можно было передать только конечное множество типов. А внутри касты интерфейсов к типам.

Это одна из самых мерзких сторон типизации в go. Но - как есть.

Ну так посмотрите. Там объявление интерфейса с приватным методом, который ничего не делает. Потом на нужных типах эти методы «реализуют». И все для того чтобы в качестве аргумента можно было передать только конечное множество типов. А внутри касты интерфейсов к типам.

такие фокусы очень редко востребованы. Думаю можно было сделать проще, тэг какой нибудь ввести. Ну уж как сделали

такие фокусы очень редко востребованы. Думаю можно было сделать проще, тэг какой нибудь ввести. Ну уж как сделали

А тэг потом как хендлить будешь

Свитчем?? И кастом значения из "* void*?

погодите

вам по-любому нужен там switch или пачка if

Вот именно. Можно подумать паттернамтчинг чем то лучше

потому как параметр вы получили, но на разные параметры вам нужна разная обработка, правда?

Вот именно. Можно подумать паттернамтчинг чем то лучше

Exhaustive checking-ом лучше

потому как параметр вы получили, но на разные параметры вам нужна разная обработка, правда?

Да, все верно. Просто парень выше говорит, что паттерн метч - говно не читабельное

Так если тот же свитч, только безопасный, в чём не читабельность?

Я так регулярно делаю в случаях работы с деревьями с разнотипными нодами. Switch, даункаст из интрфейса (не пустого). Ни разу проблем не возникало. Никакие стат. гарантии на фиг не впёрлись. Проблема высасона из пальца

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

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

и метод You shall not pass)

Я так регулярно делаю в случаях работы с деревьями с разнотипными нодами. Switch, даункаст из интрфейса (не пустого). Ни разу проблем не возникало. Никакие стат. гарантии на фиг не впёрлись. Проблема высасона из пальца

На лоре есть одна персонаж, Iron_Bug, она то же самое всегда про сишку говорит. А все остальные языки, по её мнению, для хипстеров и неосиляторов.

Я так регулярно делаю в случаях работы с деревьями с разнотипными нодами. Switch, даункаст из интрфейса (не пустого). Ни разу проблем не возникало. Никакие стат. гарантии на фиг не впёрлись. Проблема высасона из пальца

Есть разные задачи, если у тебя какой-то протокол, где есть набор сообщений, какой у тебя должен быть логический интерфейс?

Но ладно, раз стат гарантии не нужны - тут все понятно, зачем тогда вообще брать язык компилируемый? На питончике ж быстрее кодится, ещё меньше гарантий

коллега, хватит вот этого, а?

нет, на питончике не быстрее

и нет, не всем нужны эти самые гарантии

Но ладно, раз стат гарантии не нужны - тут все понятно, зачем тогда вообще брать язык компилируемый? На питончике ж быстрее кодится, ещё меньше гарантий

не нужны - не вообще, а лишь в данном случае. Вот конкретно для типов сум.

вожно понимать, зачем нам вообще нужна статическая строгая типизация

вот вам - зачем?

вот вам - зачем?

Чтобы проще было писать, читать и поддерживать.

вот вам - зачем?

Сильная типизация позволяет часть контрактов протолкнуть на уровень компилятора

Если вы меня спрашиваете - то мне проще код читать со стат. гарантиями.

Чтобы проще было писать, читать и поддерживать.

это общие слишком слова

Сильная типизация позволяет часть контрактов протолкнуть на уровень компилятора

это самоцель?

это общие слишком слова

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

понятно

так вот

существует масса способов написать херню

и, к сожалению, 90% херни появляются на этапе модификации ПО

это самоцель?

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

и, к сожалению, 90% херни появляются на этапе модификации ПО

документация устаревает тогда же

и статическая строгая - она часть этой херни написать не позволяет

самую простую херню она останавливает

но - останавливает

путем - та-дам - УСЛОЖНЕНИЯ написания кода

не облегчения, и увеличения удобста

усложнения самого процесса создания ПО

ы?

усложнения самого процесса создания ПО

тех самых 10% за которыми последует 90% модификации?

всех 100%

Ну смотри, кто-то написал вебырецмворк, у которого есть метод "ендпоинт" с внутренними контрактами, но эти контракты не покрыты, он написал его очень быстро, но при этом все юзера страдают. Ну и такое же представь, только альтернативный вариант.

и, в общем, похер уже, как именно выглядит конкретный синтаксис конкретного языка

всех 100%

Но строгая статическая типизация упрощает написание и рефакторинг кода, когда кода становится много

Но строгая статическая типизация упрощает написание и рефакторинг кода, когда кода становится много

не упрощает. усложняет. но усложняет написание херни существенно больше, чем написание совместимого кода

совместимую херню при этом можно продолжать писать, ни что не мешает

Если конмпелятор гарантирует целостность switch-а по всем веткам - это хорошо, Но в Го он всё равно не гарантирует, даже в случае IAmComand. Не сказал бы я что это вызывает сильную боль

не упрощает. усложняет. но усложняет написание херни существенно больше, чем написание совместимого кода

Так, стоп, я вот рефакторил библиотеку на расте и обновлял зависимости. После написания кода я просто прошёлся по всем ошибкам компиляции и поправил их. Это при том, что зависимости обновились нехило так, вплоть до перехода с однопоточного евентлупа на тредпул

и?

и?

Если бы не компилятор, который подсказал мне где и что не так, то я бы потратил на это значительно больше времени, отлавливая баги в рантайме.