когда пытаюсь stack ghci завести

NoImplicitPrelude, без base

но та альтернативная Prelude по идее должна всё нужное импортить

ну то есть то что в ошибках оно пишет там есть

NoImplicitPrelude это не без base, это значит что нету неявного import Prelude в каждом файле

а альтернативной прелюдии скорее всего base требуется

ну когда был base в кабал файле они конфликтовали при сборке

а альтернативной прелюдии скорее всего base требуется

А разве она там сама не зависит от base? Это какие-то peer deps?

без base очень тяжко прелюдию сделать

и бессмысленно

хотя split base было бы круто

прелюдия без base - деньги на ветер

ну тип я не делаю прелюдию. я ей пользуюсь. она в свою очередь реэкспортит из base

ошибки подсказывают, что не реэкспортит

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

тем временем в 8.6 уже две фичи будут https://github.com/ghc/ghc/commit/be84823b956f0aa09c58d94d1901f2dff13546b4 правда, одобренные комитетом по фичам на этом закончились

BlockArguments - тоже мне фича

еще странностей синтаксических завезли вместо чего-нибудь полезного

BlockArguments - тоже мне фича

другая еще более незначительная

фичи, которые не "тоже мне" через комитет по фичам не проходят

я бы даже сказал что это антифича

мне от неё странно и грустно

не знаю, у меня к ней нейтральное отношение, как к \case было, может даже буду пользоваться, но не было бы ее - я бы не расстроился

нормальные фичи которые могут быть в 8.6 это QuantifiedConstraints (эта-то я думаю будет) и DerivingVia (вот тут сомнительно)

stack upgrade —git помогло

а какие фичи застряли в коммитете кроме рекордов?

а какие фичи застряли в коммитете кроме рекордов?

рекорды не проходили комитет, они как бекпак участвовали только в экспериментальном обсуждении на гитхабе

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

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

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

одна из имплементированных фич - deriving via - как пропозал еще и не оформлена даже

а, еще же и по QuantifiedConstraints нету пропозала, но что-то я подозреваю, что она вообще вне процесса пойдет

В общем изучив всякие вёб технологии я решил что JWT фуфло, лучше уж CWT

И вообще лучше без тупорылых ненужных стандартов

мнение автора может не совпадает с его же мнением когда это всё будет в проде

В общем изучив всякие вёб технологии я решил что JWT фуфло, лучше уж CWT

kerberos (нет)

керберос тоже понадобится

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

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

@catamorphism Что вы думаете о сторонниках динамической типизации?

думаю что им стоит попробовать нормальные ЯП со статической типизацией

и заживем

Возможно. Только нельзя забывать про факт, что самый популярный язык - JS - динамический, там же где-то и Python, а само ФП начиналось с динамически типизированного Lisp

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

Если типизированные языки толкать без рационализации, то это будет восприниматься как "ограничили мою швабоду!"

Возможно. Только нельзя забывать про факт, что самый популярный язык - JS - динамический, там же где-то и Python, а само ФП начиналось с динамически типизированного Lisp

ФП началось не с лиспа, но из того с чего ФП началось был безтиповой язык Тернера

Если типизированные языки толкать без рационализации, то это будет восприниматься как "ограничили мою швабоду!"

Любопытно узнать, свободу делать что именно?

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

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

Любопытно узнать, свободу делать что именно?

свободу помещать списки и числа в один список

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

А было такое в личной практике: человек нафигачил код, скажем, на условном Python, потому что он был один, без старших товаришей, а потом свалил? У меня было.

свободу помещать списки и числа в один список

Но мне не ясно, что в этом плохого.

А было такое в личной практике: человек нафигачил код, скажем, на условном Python, потому что он был один, без старших товаришей, а потом свалил? У меня было.

Ты свалил?

но, конечно, SASL был игрушечным, из нормальных ФЯ общего назначения никогда никаких безтиповых не было

Ты свалил?

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

Но мне не ясно, что в этом плохого.

В этом и нет ничего плохого, достаточно сильная система типов дает heterogeneous lists

Но мне не ясно, что в этом плохого.

особо плохого в этом нет, правда и хорошего тоже

В этом и нет ничего плохого, достаточно сильная система типов дает heterogeneous lists

В таком случае сторонники динамической типизации бы спросили: зачем наворачивать столько оверабстракций, если тот же результат можно получить с динамической типизацией.

В таком случае сторонники динамической типизации бы спросили: зачем наворачивать столько оверабстракций, если тот же результат можно получить с динамической типизацией.

результат все же отличается

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

Any

В Скале?

эни это не аналог нетипизированного языка. Аналог нетипизированного языка это скарее тип вроде Value из aeson, только расширенный функциями, естественно

С моего текущего проекта ушел единственный рубист, потому что ему крайне не по нраву, что начали писать на Haskell с этой вашей статической типизацией.

эни это не аналог нетипизированного языка. Аналог нетипизированного языка это скарее тип вроде Value из aeson, только расширенный функциями, естественно

Мне больше показалось, что тип Value из Aeson - это аналог variant_t из плюсов

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

Как он это сделал?

Джависты же непробиваемые

ну он там их поставил перед фактом что надо на кложуре теперь писать - и половина или больше даже ушли

Он был тимлид? Или привелигированный разработчик? Все равно не ясно, как он это умудрился сделать.

А что за ФП чатик?

это же история, рассказанная в чатике, не обязательно чтоб ей соотвествовали в точности какие-то события в реальной жизни

Окей, вы меня раскусили, что я хотел за пруфами слазить

Подробное описание кейса. Как product owner я предоставил команде выбор: или пишите на любимой java или я вас могу переучить clojure. Они подумали и решили что java, аргументировав тем что быстрее надо фичи выводить, а обучение новому языку потребует времени. Ну ок, мое дело бэклог и вижн продукта. Начались спринты: 1,2,3,4 .. После 4 спринта стало окончательно ясно, что чуваки вместо продукта делают церемонии в java: пилят ORM, делают обертки, фабрики и прочее, что принято в java мире. На каждую маленьккую задачу рождалось тонны кода, который еще внезапно не многопоточный, мутабельный со всех строн, на что просились дополнительные ресурсы. Это не только у меня. В соседних стримах по платформам банка это видно. Но хуже всего было то, что я тратил 1 день clojure, чтобы показать им, что они должны были сделать за спринт всей командой. Кроме шуток, после их объяснения почему что-то не получилось, я показвал им сам демо и встречал это полным молчанием. Как-то только от javaистов требовалось сделать что-то не как в их любимом фреймворке, то сразу стекланные глаза и завышение оценок в 2-3 раза. После 4 спринта им было предложено прекратить тратить деньги организации "делая java" и переучиваться на clojure или уйти. Да, ушла ровно половина. И это пошло на огромную пользу продукту. Во-первых остались только мотивированные на создание продукта люди, а не на их java. Во-вторых набор новых высокомотивированных людей повысил общую атмосферу работы до дружеской и да еще писать на Clojure. Я согласовал затраты с боссами и 1,5 мес мы "жгли" деньги на обучение Clojure ребят. Уже после 1х спринтов вчерашние java'исты стали во-первых выводить фичи, а во-вторых они признавали что все получается заметно короче, а главное код проще.

т.е. он их не сразу выгнал, а сначала напугал

Круто

первую часть где он один побеждает легионы джавистов я пересказывать не стал, чтоб поддержать какую-никакую но реалистичность истории

Подробное описание кейса. Как product owner я предоставил команде выбор: или пишите на любимом haskell или я вас могу переучить clojure. Они подумали и решили что haskell, аргументировав тем что быстрее надо фичи выводить, а обучение новому языку потребует времени. Ну ок, мое дело бэклог и вижн продукта. Начались спринты: 1,2,3,4 .. После 4 спринта стало окончательно ясно, что чуваки вместо продукта делают церемонии в haskell: пилят типы, делают DSL, монады и прочее, что принято в haskell мире.

Oh, exploitable!