на язык сам по себе, без инфраструктуры и экосистемы, совершенно наплевать и растереть

Это чисто бизнес подход, ЯП ещё можно оценивать с точки зрения академической, исследовательской. Ещё язык можно оценивать по перспективам, которые он открывает.

Если оценивать ЯП с точки зрения бизнеса, то устанешь гоняться за хайпом.

Ибо бизнесу нужны программисты, которые будут решать проблемы, и ему не важно каким ЯП их будут решать. А программисты бывают ветренными, могут быть зависимыми от авторитетов, таких как гугл(или оракл когда-то). Да что уж говорить, если есть куча программистов, которые даже не совсем понимают, что такое система типов, термин тип-сумма вызывает у них недоумение и при этом они занимают позиции сеньёров и тимлидов.

У работодателей еще есть небезосновательный аргумент, по той причине, что хороший разрабоотчик на одной работе обычно больше 2-3 лет не задерживается, то: "как легко будет потом найти человека, который будет поддерживать всё то, что написал этот разработчик".

И проще всего такое работает с чем-то типа nodejs потому что жсников как грязи.

И проще всего такое работает с чем-то типа nodejs потому что жсников как грязи.

Это, кстати, очень забавно, учитывая насколько плох дизайн у JS

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

Ибо бизнесу нужны программисты, которые будут решать проблемы, и ему не важно каким ЯП их будут решать. А программисты бывают ветренными, могут быть зависимыми от авторитетов, таких как гугл(или оракл когда-то). Да что уж говорить, если есть куча программистов, которые даже не совсем понимают, что такое система типов, термин тип-сумма вызывает у них недоумение и при этом они занимают позиции сеньёров и тимлидов.

Кошмар какой, и часто вы используете такие типы в реальной разработке?

Кошмар какой, и часто вы используете такие типы в реальной разработке?

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

Или конечные автоматы на строковом/численном представлении состояния

Вообще, конечные автоматы без алгебраических типов данных - это сплошной набор костылей

А ещё парсеры без ADT - тоже очень творческая задача по придумыванию костылей разных форм и размеров

Ибо бизнесу нужны программисты, которые будут решать проблемы, и ему не важно каким ЯП их будут решать. А программисты бывают ветренными, могут быть зависимыми от авторитетов, таких как гугл(или оракл когда-то). Да что уж говорить, если есть куча программистов, которые даже не совсем понимают, что такое система типов, термин тип-сумма вызывает у них недоумение и при этом они занимают позиции сеньёров и тимлидов.

Вот и хорошо, пусть молятся на Пайка и других отцов-осннователей голанга. У меня к ним тоже больше доверия чем к Данику Абрамову и Одерски.

Ибо бизнесу нужны программисты, которые будут решать проблемы, и ему не важно каким ЯП их будут решать. А программисты бывают ветренными, могут быть зависимыми от авторитетов, таких как гугл(или оракл когда-то). Да что уж говорить, если есть куча программистов, которые даже не совсем понимают, что такое система типов, термин тип-сумма вызывает у них недоумение и при этом они занимают позиции сеньёров и тимлидов.

Тип сумма нужна там, где бизнес задача представляется в виде нетривиальной алгебры. Что для типичных круд сервисов по перекладыванию из жсон в хмл или базу - нонсенс. Поэтому тимлидам в массе своей на фиг не впёрлись эти ваши типы суммы

Я бы сказал, что типы суммы нужна там, где бизнесу необходимо сдать теории множеств злому лектору. А если сдавать не надо, или лектор добрый, то можно и без них обойтись

Тип сумма нужна там, где бизнес задача представляется в виде нетривиальной алгебры. Что для типичных круд сервисов по перекладыванию из жсон в хмл или базу - нонсенс. Поэтому тимлидам в массе своей на фиг не впёрлись эти ваши типы суммы

Да человек просто хотел выпендриться а ты сейчас будешь доказывать что он не прав )

Вот и хорошо, пусть молятся на Пайка и других отцов-осннователей голанга. У меня к ним тоже больше доверия чем к Данику Абрамову и Одерски.

Очень странным образом вы своё доверие даруете. Я бы, например, не доверял попыткам Одерски разрабатывать ОС, и не доверяю попыткам Пайка разработать язык программирования. Аргументация проста - это за пределами их профессиональной компетенции.

Я бы сказал, что типы суммы нужна там, где бизнесу необходимо сдать теории множеств злому лектору. А если сдавать не надо, или лектор добрый, то можно и без них обойтись

Ваш мир ограничивается только крудами да лекторами в университете?

Пайку доверять можно, опыт в Bell Labs, много OS экспериментов, много концепций, создатель UTF8, фантастический текущий проект upspin

Да человек просто хотел выпендриться а ты сейчас будешь доказывать что он не прав )

это понятно что выпендрится. не то что бы доказывать - ясность внести)

это понятно что выпендрится. не то что бы доказывать - ясность внести)

Уверен, что если бы бизнес не заставил его отыскать в каких-то закромах эту тип-сумму, сам бы про неё он не узнал. Зато понтов перед соискателями выше крыши - они приходят на собес, а он им - Как, вы не знаете тип-сумму?! Видал я это на собеседованиях, неприятно, пипец.

Пайку доверять можно, опыт в Bell Labs, много OS экспериментов, много концепций, создатель UTF8, фантастический текущий проект upspin

И ни одного ЯП до 50+ лет.

Уверен, что если бы бизнес не заставил его отыскать в каких-то закромах эту тип-сумму, сам бы про неё он не узнал. Зато понтов перед соискателями выше крыши - они приходят на собес, а он им - Как, вы не знаете тип-сумму?! Видал я это на собеседованиях, неприятно, пипец.

Меня никто не заставлял искать тип-сумму. Я это сделал в рамках личного времени потраченного на самообучение.

И ни одного ЯП до 50+ лет.

известных нет, но много типа newsqueak и т.п. - всё шло в копилку, там тоже CSP

Меня никто не заставлял искать тип-сумму. Я это сделал в рамках личного времени потраченного на самообучение.

Много теперь где применяешь ?

Много теперь где применяешь ?

Опять же не в рабочее время, ибо на работе языки, где их и в помине нет. Хотя часто вижу ситуации, когда нужен простой тип сумма, а вместо этого приходится городить костыль

Уверен, что если бы бизнес не заставил его отыскать в каких-то закромах эту тип-сумму, сам бы про неё он не узнал. Зато понтов перед соискателями выше крыши - они приходят на собес, а он им - Как, вы не знаете тип-сумму?! Видал я это на собеседованиях, неприятно, пипец.

а может пред работодателями? ;) Я вот таких видал - это ещё смешнее

Опять же не в рабочее время, ибо на работе языки, где их и в помине нет. Хотя часто вижу ситуации, когда нужен простой тип сумма, а вместо этого приходится городить костыль

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

И ни одного ЯП до 50+ лет.

Сразу заметно, критика из разряда “сам не читал, но не одобряю” ? Чтобы что-то или кого-то критиковать, надо иметь хотя бы какое-то представление ?

что за тип-сумма, чем знаменита?

https://ru.wikipedia.org/wiki/%D0%A2%D0%B8%D0%BF-%D1%81%D1%83%D0%BC%D0%BC%D0%B0

это?

что за тип-сумма, чем знаменита?

type Maybe v = Just v | Nothing

type Either a b = Left a | Right b

Это чисто бизнес подход, ЯП ещё можно оценивать с точки зрения академической, исследовательской. Ещё язык можно оценивать по перспективам, которые он открывает.

а нет другого подхода кроме бизнеса. Изследователи-искатели которые всю жизнь пишут факториал или фибоначи на монадах никому не нужны

type Either a b = Left a | Right b

чет легче не стало от твоих подсказок

это какая-то нечеткая логика?

чет легче не стало от твоих подсказок

Это тип который может содержать значение одного из конечного числа типов. Типом суммой называется потому-что количество значений такого типа = количество значений 1 типа + количество значений 2 типа + ... + количество значений N типа

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

Это тип который может содержать значение одного из конечного числа типов. Типом суммой называется потому-что количество значений такого типа = количество значений 1 типа + количество значений 2 типа + ... + количество значений N типа

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

Естественно что рядом собственно со значением должна лежать метка того, какой там лежит за тип. Иначе условие > количество значений такого типа = количество значений 1 типа + количество значений 2 типа + ... + количество значений N типа не выполняется

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что за книгу?

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

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

Что за книгу?

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

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

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

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

+

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

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

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

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

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

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

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

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

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

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

ERROR: S client not available

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

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

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

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

уровня /go ?

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

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

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

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

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

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

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

погодите

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

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

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

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

Exhaustive checking-ом лучше

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

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

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

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

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

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

и метод You shall not pass)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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