с 20 минуты примерно

"I think types are an antipattern for program maintenance and extensibility."

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

>>1081490
>кьюшники
>джира
Да вы, товарисчь, говноед.

>>1081492
Я? Увольте.
Я описал типичный процесс каждой ашот-ауторцс конторы.
Учитывая что макаки не в курсе, что их сисярп и жаба даже не статические типизированы в сравнение с тем же вселюбимым петухаскелем, а типы сугубо номинальные. Нахуя им типы тогда, в этих недоязыках, хуй знает

>>1081268 (OP)
Ну все, пацаны, выкидываем всю теорию типов, все языки с какой-либо статической типизацией, это все нахуй не нужно оказывается

пиздос ну раз Рич Хикка сказал тогда ладно

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

>>1081526
Зачем ты вкидываешь фотки ученых\логиков\философов\твоей мамки? Это все не имеет никакого отношения к программированию\разработке приложений. Почему ты с этими фотками в трежд к каким-нибудь архитекторам или проектировщикам станков не закатываешься?

>>1081490
А как же микросервисы? Даем макаке спецификацию, даем макаке наши либы - пусть пишет там что хочет, багов в жиру накидаем, все ок.

Если я тебя правильно понял, конечно.

>>1081534
1. доска называется Программирование
2. программирование подразумевает языки программирования
3. в нормальных языках применяется теория типов Мартина-Лофа и исчисление конструкций.
в хуёвых недоязыках - не применяется, да, но это проблемы тех, кто на них пишет

>>1081535
>А как же микросервисы
Хуервисы. От того что ты разломаешь монолит на сервисы, легче поддерживать его не станет, только вовлечёт больше сложности и неопределённости. Никакую спецификацию ты не даёшь, потому что везде аджайл, и в лучшем случае ты дашь неполную юзер стори. Ну и дальше фисинг багов сжирает времени больше дедлайна и все отправляются на переквалификацию в макдональдс.

>>1081541
>3. в нормальных языках применяется теория типов Мартина-Лофа и исчисление конструкций.
Вот тут ошибочка, исправляйся.

>>1081542
Кокой ты пессимист. Ну я это к тому, что без разницы, типами мы макаку обжимаем или спекой протокола, который ему нужно заимплементировать. Второе хотя бы универсальнее.

>>1081588
Какими блять спеками? Кто их писать-то будет? На типы тривиальную программу макака разложить сама сможет пока будет программировать. А если дать макаке динамическую дрисню - она высрет баше-подобное спагетти, и дальше вы либо ебашите юнит и проперти тесты, и в результате работает приблизительно с той же скоростью, что и статические макакены, либо не ебашите тесты и тогда закрываете спринт быстре, но потом еще два фиксите баги.

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

>>1081672
Ой блядь, ну если мы даем макаке что-то писать, то это явно не пустой проект, не? Значит у нас уже есть какой-то потребитель, которому нужно дернуть какое-то новое апи. Мы этот апи описываем, ставим задачу, скорее всего даем какой-то наш внутренний фреймворк, по которому макака будет хуячить, даем ГЕНЕРАТИВНЫЙ в идеале интеграционный тест-сьют, все. Юнит там тесты, не юнит, типы там, хуипы - вообще не ебет, единственные реальные границы - это границы процессов, единственная реальная точка стабильности - это межпроцессные протоколы.

Спагетти блядь, я посмотрю как макакены на *мл неспагетти писать будут. Вот с ней как раз надо быть дохуя опытным и обладать нихуевой интуицией, ну либо перепиздаривать все по 10 раз. А тут - хуяк-хуяк и в продакшн, вообще похуй.

>>1081934
>Мы этот апи описываем, ставим задачу
В разработке большая часть времени тратиться на выявление бизнес-правил, и так выходит, что бизнес полностью эти правила сформулировать не может, большая часть противоречий, неполноты информации и разрешения различных вариантов происходит уже на этапе разработки. Написать исчерпывающую спецификацию = решить 80% задачи.

>даем какой-то наш внутренний фреймворк
А кто этот фреймворк напишет?

>даем интеграционный тест-сьют
А кто его будет писать, поддерживать и расширять? И ты собрался тестировать интеграционными тестами хуйню, которая будет падать от undefined is not a function?

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

>>1081268 (OP)
Понимание типов товарищем Хикки практически на 100% ограничено мирами C++ и Java, о полноценной type-driven разработке на Haskell / Scala / Idris он и понятия не имеет, это совершенно другой мир.

>>1081977
> Написать исчерпывающую спецификацию = решить 80% задачи.
Блядь, ну при чем тут исчерпывающая спецификация? Ты задачу своей макаке как-то ставишь? Как-то ставишь. Надо тебе, не знаю, какой-нибудь файлик хитровыебанного формата от какой-нибудь местной конторы запихнуть в свою опердень. Ты берешь своего падавана, даешь ему ссылку на спеку этого формата и говоришь, что мы будем твою прогу так-то и так-то дергать, пиши результат туда-то и туда-то, ну и таймаут тебе будет такой-то и такой-то. Не знаю, хоть это студент-олимпиадник, который тебе на си с хуйцами наложит невменяемого говнокода, который зато будет работать и притом быстро. Либо пхп-говнокодер, который твой рест теребить будет. Либо сам саймон пейтон джонс, который захерачит там монадных трансформеров у себя внутри. Я не знаю, мне ПОХУЙ, что там у него внутри.

Я вот об этом, понимаешь? А ты - бизнес-правила, бла-бла. Ну изменятся требования - изменим задачу, перепишем, переделаем, это выбросим, то добавим. Это вообще никакого отношения к вопросу типов не имеет, это все очевидные вещи.

> А кто этот фреймворк напишет?
Сеньор\предыдущая команда\интеграторы\отдельные внутренние ребята, я ж не знаю, о каком масштабе речь идет. К чему этот вопрос вообще?

> падать от undefined is not a function
Ой блядь, ну не надо вот этих сказочек. Мне - повторюсь еще раз - абсолютно ПОХУЙ, падает оно от андефайнед из нот э фанкшн или от нуллпоинтер эксепшна. Вообще однохуйственно. Оно либо работает, либо не работает. И тестирование придется проводить вне зависимости от того, йобалишп там у тебя, джава или х-ль.

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

>>1081987
Охуеть. Ну ты бы хоть ток из оп-поста посмотрел, он там как бы половину времени говорит именно о х-ле и прочих мл-лайк, в том числе и о "тайп-дривен" разработке.

Ну и вообще странно слышать такие предъявы в адрес евангелиста функциональого программирования. Подозреваю, что он прочитал и написал больше кода на статико(няше|параше), чем все итт аноны вместе взятые. Но это не точно.

>>1082027
>Подозреваю, что

>пук
>что-то подозревает

>>1082220
Школота, /b вон там.

>>1082343
только Idris, только завтипы!

>>1082020
Да нет тут никакого пойнта. Talk is cheap.

>>1081268 (OP)
Каюсь, недоработали, не просветили дяденьку. Дико проиграл с "you don't have a burden of proof"

>>1082393
Ну раз школоло из зыча так говорит, то ладно.

>>1082415
В чём смысл твоего поста?
Ты говоришь: вот у нас есть готовые спеки, готовый йоба-фреймворк и готовый йоба-тест-фреймворк, осталось посадить макак переводить спецификации в команды фреймворка и тестов. Т.е. изначально задаёшь условия, когда все проблемы уже решены.

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

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

>>1082486
>В чём смысл твоего поста?
Ну для начала ты бы мог его просто перечитать - глядишь и вопросы бы отпали.

Смысл моего поста в том, что без разницы, на чем написаны отдельные компоненты системы - на статикодрисне или на динамикодрисне. Важны протоколы связи между ними. Протоколы и спецификации данных. Их должен разрабатывать опытный чувак. А реализовывать эти компоненты могут и джуниоры - и без разницы, с типами или без. Что-то мне подсказывает, что джуниор на каком-нибудь руби напишет гораздо более вменяемый код, чем на х-ле, причем за более короткое время. Ну это так.

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

Касательно "на чем писать йобафреймворк" - беспонтовый вопрос. Зависит (очевидно) от того, что он должен делать, под какой платформой работать, с чем у команды есть опыт и т.п. Как-то наивно делить все на "динамикодрисню" и все остальное. Ты джаву, си и окамл в одну категорию скидываешь? Ну удачи, хуль.

>>1082559
двойную порцию скобок этому адеквату

>>1082559
Видос я разумеется не смотрел, потому что смотреть высеры Хикки, это как смотреть высеры Алана Кея и прочих любителей много пиздеть ни о чём, срывать покровы и изобретать велосипеды с необычными новыми названиями и т.д.

В статике протоколы и спецификации - это и есть твои типы, как и все остальные сущности в программе. В динамике для этого по видимому используется какое-то говно с рантам валидаторами или полумеры, типа gradual typing.
Не иметь разделения тестов на unit и ingegration - это идиотизм. Одно дело когда тест упал, потому что вызов сервиса должен был вернуть тебе список с одним элементом, а вернул с двумя, другое дело когда он упал с 500, потому что в где-то в кишках сложили флоат со строкой. Интеграционные тесты должны тестировать логику, а не ошибки типов. Они пишутся дольше, отрабатывают медленнее, поддерживать их сложнее, отлаживать баг тоже сложнее. В статике можно обойтись только ими, потому как от ошибок типа "сложили дилды со строками" мы застрахованы. Как и от ошибок, типа положили в таблицу дилду вместо строки, и забыли про неё, через два дня какой-то вызов обратился к этой записи и всё наебнулось где-то далеко в кишках, удачной отладки.

Разделение на компоненты никак проблемы динамикодрисни не решает. Вместо падающего от undefined is not a function монолитного приложения, у тебя будет будет та же самая ошибка, от того, что у тебя упал один из сервисов. Только повышается сложность.

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

>Ты джаву, си и окамл в одну категорию скидываешь?
Конечно, спокойно можно обобщить скажем джаву и окамл в рамках одной категории, и общего у них будет больше, чем у любого из них, скажем, с питоном или кложей.

>>1082020
> Мне - повторюсь еще раз - абсолютно ПОХУЙ, падает оно от андефайнед из нот э фанкшн или от нуллпоинтер эксепшна.
Зачем ты пишешь о том, в чем не разбираешься? NPE возникает из-за того, что макаки используют null вместо Optional.empty, чтобы обозначить отсуствтие значения. То есть, эта ошибка вызвана тем, что система типов не используется. Представь что return type метода User, но он может вернуть null. null - это не User, вот в чем проблема. Если юзер может отсутствовать, он должен возвращать Optional<User>. Существование null - это ошибка дизайна языка, которую нельзя исправить, потому что принципиальная позиция джавы - не ломать обратную совместимость.

>>1082577
> Не читал, но осуждаю
Ну... в таком случае приходится признать, что ты - уж извини за прямоту - зашоренная пидораха с хуевым кругозором и православием типославием головного мозга, или что там у тебя. Совсем недавно индустрия массово производила таких же упертых ООП-фанатиков, теперь вот вектор развития чуть-чуть сместился. Но это так, лирическое отступление, прямого отношения к дискуссии не имеющее.

> В статике протоколы и спецификации - это и есть твои типы
У тебя какие-то проблемы с пониманием написанного. Я тебе уже дохульон раз сказал, что НЕТ ТВОИХ ТИПОВ ЗА ПРЕДЕЛАМИ ТВОЕЙ ПРОГРАММЫ АЛЕ ПОНИМАЕШЬ ТЫ ЭТО ИЛИ НЕТ ТВОЙ ТАЙПЧЕКЕР ЗА ПРЕДЕЛАМИ ТВОЕЙ ПРОГРАММЫ НЕ РАБОТАЕТ. Сколько еще раз надо повторить?

> Не иметь разделения тестов на unit и ingegration - это идиотизм.
Это ты к чему вообще? Я где-то утверждал обратное?
Ты с кем сейчас разговариваешь?

> Интеграционные тесты должны тестировать логику,
Ты не поверишь, но вообще-то любые тесты должны тестировать логику.

> сложили дилды со строками
Ну если ты РАЗРАБОТЧИК уровня laba2.cpp, то для тебя такие ошибки актуальны. Но о чем мне тогда с тобой вообще разговаривать?

> Только повышается сложность.
Разделение на компоненты повышает сложность. Вот это откровения. Абстракция - это инструмент повышения сложности. Понятно.

> фреймворк
По поводу "фреймворка" я тебе уже объяснил, какие реальные фактора реального мира влияют на его создание. Твоя мантра "динамикодрисня все поломает" попросту выдает в тебе дилетанта.

> джаву и окамл в рамках одной категории
А си? Ты си забыл обобщить в категорию, исправляйся.

>>1082746
Ты диалог-то перечитай, коль память коротка, але. Свои же посты причем. Разговор и шел о макаках, у которых в динамикодрисне будет андефайнед, а в статикодрисне - нпе.

>>1082821
Не будет у них в статикодрисне нпе, я своих макак приучил, все норм, крашей в разы меньше. Если совсем тяжко, можно линтеру правило въебать.
Мимосвифтоблядок

>>1082819
Зачем нужно иметь типы за пределами программы? Типы решают проблему внутренней противоречивости.

>Я где-то утверждал обратное?
>>>И ты собрался тестировать интеграционными тестами хуйню, которая будет падать от undefined is not a function?
>>Оно либо работает, либо не работает

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

>Разделение на компоненты повышает сложность. Вот это откровения. Абстракция - это инструмент повышения сложности.
Нахуя ты передергиваешь? Ты отличаешь разделение компонентов на уровне выделил повторящийся код в отдельную функцию/модуль, от выноса логики в отдельное приложение запущенное на другом узле? Особенно в свете последней моды разделения на микросервисы ради микросервисов, а не потому что для приложения это имеет смысл.

>какие реальные фактора реального мира влияют на его создание.
Какая разница что на него влияет или нет? Как это отменяет мой вопрос? Ты всё равно или берёшь статику и, таким образом, защищается от ошибок типов в рантайме , либо берёшь динамику и насасываешься.

> Ты си забыл обобщить в категорию
Зачем? Думаю понятно, что говорим про нормальную статику, хотя бы уровня джавы/сишарпа.

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

Давай ты ещё раз попробуешь ответить на изначальный вопрос: как разделение на сервисы решает проблему динамической типизации (думаю эта проблема вполне ясно обозначена).

>>1082392
Так и в скала зависимые типы

>>1083054
Ну так речь идет о чём-то посолиднее, чем path-dependent-types.

>>1082894
Так из внешнего же кода все равно нули приходить будут. Все-таки эта проблема должна на уровне языка решаться. А приучить и правило въебать можно, опять же, вне зависимости от того, какая у нас система типов.

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

> расширяется множеством ошибок типов
Да блядь, в каждом подобном разговоре какой-нибудь статикофанатик обязательно про это скажет. Я в прошлом посте уже сказал - если ты делаешь такие ошибки, значит ты кодер уровня laba2.cpp. Вот блядь, я могу копипастить свои предыдущие посты тебе в ответ, серьезно. Пиздец какой-то.

> в отдельное приложение запущенное на другом узле
Ты так говоришь, как будто тебе при добавлении каждого нового компонента инфраструктуру с нуля поднимать приходится. Один раз засетапил - дальше пиши уже по установленным рельсам, все однообразно. А с отдельными приложениями на других узлах тебе все равно придется общаться, если у тебя, ну не знаю, хотя бы база и веб-морда есть.

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

> говорим про нормальную статику, хотя бы уровня джавы
Лол, ну ты юморной парень, оценил тебя.

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

> Давай ты ещё раз попробуешь ответить на изначальный вопрос
Давай лучше ты попробуешь перечитать мои ответы и четко сформулировать, что конкретно тебе непонятно и с чем ты не согласен. Пока все твои посты сводятся к "не читал, но осуждаю" и "или берёшь статику, либо берёшь динамику и насасываешься))".

>>1083092
>Так из внешнего же кода все равно нули приходить будут.
Может ты еще и тестируешь внешние библиотеки?
>Все-таки эта проблема должна на уровне языка решаться.
Все на уровне языка и решается, в отличие от динамикодрисни, где погромист сам должен в голове держать ненужную хуйни и писать убогие тесты, чтобы с типами в рантайме не объебаться.

Пустой тред, специальная олимпиада.
Итт выдомые Ричем Хиккой и Джо Армстронгом блаженные разработчики систем спорят с школьниками ебашащими легаси на джаве и не знающих других путей.
Первые даже когда объясняют, то вторые не догоняют и говорят про то что надо защищацца от сложения строк с гусями :)
Но таки Рич и Джо правы, типы это не путь софтварного джедая, они сгущают мозги и заставляют писать тебя в обосранном защитном стиле.

>>1083092
вот это разрыв динамикодауна, просто эпик

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

>>1083190
Так и помогают, от багов спасают не типы, а иммутабельность и хорошо прописанные протоколы с валидацией. Типы заставляют тебя писать в защитном стиле, вместо изящных абстракций заставляют описывать бойлерплейты дженериков. Еще не понятно как могут ужиться вместе типы и метапрограммирование. У типов много недостатков, на которые Рич Хикки указывает. Ты же даже видео то не посмотрел, но уже успел назвать его фюрерком. В общем я дальше не буду пояснять, так как уже написал в сообщении выше, считаю это специальной олимпиадой. Кому надо типы, те пишут на идрисах и хаскелях. Кому надо динамика пишут на кложе и эликсире. Жабу и сишарп оставим ентерпрайзу, там не инженеры решения принимают и это отражается на дизайне языков.

>>1083190
Потыкал палочкой в шизика.

>>1083244
>иммутабельность
Иммутабельность спасает от проблем связанных с мутабельностью, а не с ошибками типов, внезапно. От ошибок типа сложили дилду со строкой, или перепутали местами номер заказа и номер счета она тебя не спасает.
>хорошо прописанные протоколы с валидацией
Валидация запросов никак не гарантирует тебе внутренней корректности твоего кода. Внешне правильные данные в результате преобразований внутри самого сервиса могут принять тип, не тот что ожидается, и дальше произойдёт ошибка: в лучшем случае сразу, в худшем случае она будет иметь вероятность возникновения 0.01% и воспроизводиться со специфическими условиями, и в совершенно другом месте и другое время (например, в случае складирования в in memory хранилище, как тут уже говорили).

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

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

>Еще не понятно как могут ужиться вместе типы и метапрограммирование.
Template Haskell посмотри, например.
А вообще, повсеместное использование метапрограммирования, свидетельствует о недостаточной выразительности языка, а не наоборот, как думают некоторые скобкопетухи.

>Кому надо типы, те пишут на идрисах и хаскелях. Кому надо динамика пишут на кложе и эликсире.
Ну и прекрасно, на этом и закончим, значит.

>>1083291
>некоторые скобкопетухи
:)
http://www.lispcast.com/clojure-and-types

>Ну и прекрасно, на этом и закончим, значит.
Всего хорошего!

>>1083244
>Кому надо динамика пишут на кложе и эликсире
Что пизже, кложа или эликсир?

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

>>1083291
>использование метапрограммирования
>недостаточной выразительности языка
Базовый язык может быть насколько угодно невыразительным. Метапрограммирование позволяет сделать его более выразительным. А макросы позволяют поднять выразительность лиспа в космос, недоступный статикопетухам.

Вообще я думаю так: типы это наиболее обобщённая и универсальная концепция, которая только есть в программировании. Она прекрасно отражает само построение предметной области. Любой программист строит предметную область, и использует типы у себя в голове, даже если пишет на бестиповом ЯП.
Другое дело, что многим программистам просто не нужна настолько универсальная система, как, скажем, система типов хаскеля. Например, для типичной веб-макаки достаточно уже готовых типов, которые необходимы для решения основных проблем, которые возникают при построении веб-приложения.

Возьмём Elixir/Phoenix, к примеру. Предметная область в типичной крудошлёпстве строится от базы. Схемы отражают сущности базы в коде. В схемах описываются сущности как типы-произведения, типа %User{...}, %Order{...}, с фиксированным набором полей определённых типов и связями с другими сущностями. Преобразования над ними описываются типом Changeset и применяются в одноимённом модуле с операциями с типами Schema -> Params -> Changeset и Changeset -> Params -> Changeset. Модуль для работы непосредственной с базой содержит операции с типами Changest -> Schema | Changeset. Так же есть вспомогательные модули для композиции, где операции имеют тип Multi -> Changeset -> Multi и Multi -> Multi -> Multi. Этих типов хватает чтобы покрыть большую часть приложения (сущности и операции над ними). Так же в крудошлёпсте второй по важности является работа с запросами. Запрос представляется типом %Plug.Conn{} и работают с ним с помощью плагов, имеющих сигнатуру init:: Plug.Opts -> Plug.Opts (для праметризации) и call :: Plug.Conn -> Plug.Opts -> Plug.Conn (для трансформации). Т.е. запрос просто проходит через конвейер из плагов. Этими типами покрывается почти 90% работы приложения. Всё что остаётся сделать - это написать логику, которая будет делать Plug.Conn -> Changeset (из запроса в сущность) и Changest | Schema -> Plug.Conn (из сущности в ответ), большая часть которой уже реализована фреймворком. Т.е. для тривиальных крудошлёпских приложений никакая система типов не нужна, достаточно конкретных типов, которые предоставляет фреймворк. Но это никак не отменяет использования типов как таковых и их универсальности как базовых элементов построения любой программы. Например, для задач сложнее (типа написания yoba-транслятора) каких-то там встроенных типов недостаточно и нужно иметь возможность создавать свои.

>>1083122
Хуйню сказал, перечитай.

>>1083137
Same old shit, ага.

>>1083190
Типичный хаскелл-фанбой, посмотрите. ( ° ʖ °)

>>1083291
>а я вот хочу проверять правильность того, что я пишу.
А вот если бы ты прочитал хоть одну книжку про ТИПЫ, то узнал бы, что тайпчекер на правильность твой код не проверяет.

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

>>1083456
Ты не поверишь, но в кложе есть опциональный статик тайпинг + статическая проверка статических частей спеков.

Алсо, типы != зашитый в компилятор статик тайпчекинг, если уж на то пошло.

>>1083528
Да нахуй нам макросы, когда у нас столько лангуэйдж фьючерсов есть! И главное - НИ ЕДИНОГО КОНФЛИКТА!!11 %)

>>1083545
Типы никогда не используются для описания предметной области, если эта предметная область чуть сложнее вычисления факториала.

В хаскеле ужасно слабая, невыразительная и неуниверсальная система типов. Твое утверждение об обратном выдает в тебе ньюфага.

>>1083579
> типы != зашитый в компилятор статик тайпчекинг

Конечно не равно, важнен только иде чекинг

>>1083752
>иде
Ненужно!!111

>>1083580
Ебать жир.

>>1083867
Когда что-то непонятно - не стесняйся спрашивать. Это же /pr.

>>1083580
>ужасно слабая, невыразительная и неуниверсальная система типов
Реквестирую язык с обратной ситуацией

>>1084529
Ну хаскель с более лучшими типами это идрис.

Но он тоже непрактичное говно, конечно.

>>1083579
>У них есть формальная семантика
Трансдюсер - это сломанная абстракция, которую спасают только особенности кложури.
http://thedeemon.livejournal.com/87320.html

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

>>1085902
Гхм, димон, конечно, няшка, но ты же понимаешь, что весь этот пост - толстейший троллинг? Надеюсь, что ты не принял это за чистую монету, а пытаешься теперь в свою очередь траллировать меня не выйдет :3.

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

>>тайпчекер на правильность твой код не проверяет.
>Ну смотря что ты под "правильностью" понимаешь.
Ой, ну вот что ты маневрируешь на ровном месте. Тайпчекер не проверяет код на корректность. Такой задачи перед ним, чсх, и не стоит. О чем тут спорить? Оговорился, бывает - тебя же не заставляют на бутылку из-за этого садиться, чего тут маневрировать.

>>1085921
>толстейший троллинг
Ну поведай, в чём там троллинг и почему хаки перестали быть хаками.

>Тайпчекер не проверяет код на корректность.
Типы сошлись - значит код корректный.

>>1085943
>Ну поведай, в чём там троллинг
В комментариях димону пояснили, в чем он не прав, и он тихонечко слился. Можешь прочитать как бы.

Ну и по мелочи, все его "сарказмы" сводятся к тому, что функции названы человекочитаемыми именами:
> А алгебра, что передается в катаморфизм, получила у Хики новое имя - reducerинновация!.

Или к тому, что он свой пост писал по мотивам презентации, в которой на примере объясняется, как из конкретного кода получить обобщенный, с трансдьюсером (даже слайды прикрепил):
> Если conj заменить на построитель не-векторов, а [] оставить, будет банальная ошибка типов. В этой его кложури - еще и в рантайме. Ибо про функторы с алгебрами не думал, там-то тип сразу показывает о каких вариантах надо заботиться.

Ну или опять к тому, что ему, по сути, имена не понравились - димону хочется, чтобы это были разные функции в тайпклассе, а гадкий хикка все в одну запихал:
> Хак первый: писал он на кложури, а она позволяет функции принимать разное число аргументов и в зависимости от этого вести себя по-разному. Ну и сделал, что ежели аргументов не дали, то пусть работает как вторая половина алгебры
Димон, правда, не подумал, что в кложури функции типа + выдают нейтральный элемент в нуль-арной версии и возвращают аргумент в одноарной (что, кстати, здраво и логично), и трансдьюсеры должны это использовать, а не городить отдельный велосипед, ибо обратная совместимость - но какое димону дело до обратной совместимости, на его-то уровне.

Далее он называет "хаком" eager evaluation - ну, опять же, на его уровне такие забавности простительны. Правда, он все-таки снисходит до простых смертных с энергичными вычислениями и предлагает добавить boolean-флаг в уже имеющиеся функции - до мыслей об обратной совместимости все-таки снисходить не комильфо, чай не инженер какой-нибудь.

> все эти трансменьшители сводятся к такому типу:
transducer: [a] ->
Ну собственно в комментах ему и пояснили, что не сводятся, и даже за сарказм это не катит.

> I asked @richhickey and he said "a transducer is just a pre-fused Kleisli arrows in the list monad."
Ну вот, сарказмировали-сарказмировали по поводу-де необразованности хикки, а он взял да и сам про стрелки с монадами вдруг говорить начал. Да еще и не тратя на это три экрана текста с шутками мимо кассы.

Теперь ты поясняй, что же именно из этого хак: стрелки, монады или списки?

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

>>1085959
>что, кстати, здраво и логично

Ясно. Это и есть твоя "формальная семантика"?

>>1085965
Пиздос, ну ты мегатроль просто))00))

>>1081268 (OP)
Посмотрел, интересно, правда первые 20 минут можно пропустить.