Size: a a a

2021 May 03

A

Andrey in Haskell
оба подхода:
- исследование абстракций с последующим их применением, в которых буквенные обозначения "естественны"
- промышленный, в котором наоборот обозначения принимают словесную форму, и это поощряется..

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

или оба, или что-то ещё..
а утверждать, что что-то одно > чего-то другого - не верно, вообще говоря
источник

A

Andrey in Haskell
консенсуса достичь в каждом отдельном взятом случае столкновения двух "подходов" можно, конечно.

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

АХ

Алексей Худяков... in Haskell
Если написать фиговина хреновина малявина и муровина то понятней не станет, а читать станет сложнее
источник

AS

Alexander Smirnov in Haskell
Поэтому надо писать нормально
источник

MP

Misha Puzanov in Haskell
а как написать нормально тип параметра у линзы?
Ну даже ладно линзы, есть вот Functor a — на что тут заменить a?
источник

IO

I O in Haskell
На f!
источник

MP

Misha Puzanov in Haskell
логично!
источник

Y

Yuuri in Haskell
«Писать надо хороший код, а плохой не писать. Плохой код писать плохо».
источник

KV

Kirill Valyavin in Haskell
Ну-ка, а придумайте осмысленное название для переменной типа в определении Identity a. Или Const a b. Или в forall x. f x -> g x
источник

KV

Kirill Valyavin in Haskell
Да и для классов типов можно придумать. Какой Monoid, какой Functor, что за понты, когда можно просто и понятно - appendable mappable is an appendable in the objecty-arrowy of self-transformables. Чтобы у каждого читающего создалась ложное впечатление, что ему чё-то понятно стало
источник

IO

I O in Haskell
Да даже если осмысленное название и можно придумать, имхо они почти всегда ужасно читаются в нетривиальных случаях.

Optic opticType indices outerInput outerOutput innerInput innerOutput

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

(%) 
 :: (JoinKinds leftOpticKind rightOpticKind resultOpticKind, AppendIndices leftIndices rightIndices resultIndices)
 => Optic leftOpticKind leftIndices outerInput outerOutput middleInput middleOutput
 -> Optic rightOpticKind rightIndices middleInput middleOutput innerInput innerOutput
 -> Optic resultOpticKind resultIndices outerInput outerOutput innerInput innerOutput
источник

KV

Kirill Valyavin in Haskell
Другое дело, теперь любой студент разберётся
источник

[

[BRM]White Rabbit in Haskell
Компилятор посоветовал вот такую магию включить.
За такие приколы сильно бьют в продакшене или законный экстеншен?
источник

IO

I O in Haskell
Если Вы точно понимаете, зачем вам это - скорее всего нормально, иначе - вряд ли
источник

KV

Kirill Valyavin in Haskell
Раз на раз не приходится. Если непонятно, что это, лучше не включать, а подумоть
источник

[

[BRM]White Rabbit in Haskell
Я ничего не понимаю, включил по подсказке уже 3 экстеншена, продолжает ругаться
источник

Y

Yuuri in Haskell
А что, Monoid понятнее чем Appendable?
источник

KV

Kirill Valyavin in Haskell
Понятнее, что надо посмотреть определение
источник

к

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

к

кана in Haskell
но почитать про все это конечно стоит заранее
источник