yesod не нужен был ещё в 2013

Why so radical?

А про yesod vs servant что скажете?

snap (crazy.png)

Или spock? Или вообще happstack? ?

spock норм

scotty тоже

Хапстек мёртв же

Что значит мёртв? Не работает и разлагается?

(оффтоп) Я знаю, что это канал про аниме. Что это за тайтл, не подскажете ли?

@t91x0 @flerka Так, молодые люди. Стикеры и картинки тут глубоко не приветствуются

@t91x0 @flerka Так, молодые люди. Стикеры и картинки тут глубоко не приветствуются

Вы б лучше про тайтл ответили.

Я похож на виабу?

Я похож на виабу?

Мало ли. Я знаю одного хаскелиста-трапа, который вышел замуж за скальщика и уехал в ЕС.

Он штангой занимался?

Он штангой занимался?

Нет, конечно. Тот как жил в Москве, так и сейчас живёт.

Зефиров не единственный.

Народ, плиз

Мало ли. Я знаю одного хаскелиста-трапа, который вышел замуж за скальщика и уехал в ЕС.

ФП сближает!

он был женщиной с точностью до изоморфизма

> за скальщика ужасно

Так че за аниме было выяснили?

Long variable names make code's structure harder to see. Short variable, the reader might forget the intent Compromise: Use the long name just once. tax originalAgi marginalTaxRate = a * r where a = originalAgi r = marginalTaxRate

оно и на реальныe математические выкладки похоже

по-моему годная мысль

what if tax (OriginalAgi a) (MarginalTaxRate r) = Tax (a * r)

еще и типы хорошие будут, с ньютайпами

вместо tax :: Money -> Money -> Money будет tax :: OriginalAgi -> MarginalTaxRate -> Tax

> Long variable names make code's structure harder to see сильное утверждение

оно и на реальныe математические выкладки похоже

синтетика в чистом виде

не говоря уже о том что tax = (*)

> tax :: Money -> Money -> Money rate не может быть типа Money изначально, это же рейт :)

Я не вдумывался в то, что пишу

Пусть будет Coeff или что там

Comoney

вместо tax :: Money -> Money -> Money будет tax :: OriginalAgi -> MarginalTaxRate -> Tax

мани мани мани

> Long variable names make code's structure harder to see сильное утверждение

Ну а что, не так что ли? В плане наименований переменных и типов сабж уже достиг джава-дна и не собирается на этом останавливаться. Скоро в 132'символьный терминал не будут помещаться

Типики же есть, зачем "говорящие имена", если типы "говорящие"? Вот если функция выглядит, как (говно): f :: Int -> Int -> Int -> Int f x a b = if x > 5 then a else b то в этом конкретном случае имена аргументов могут помочь. Но не сильно

Тут уже именованные аргументы нужны (как в либе от @int_index, например)

> Long variable names make code's structure harder to see сильное утверждение

в ФП это прописной истиной считается

Ну а что, не так что ли? В плане наименований переменных и типов сабж уже достиг джава-дна и не собирается на этом останавливаться. Скоро в 132'символьный терминал не будут помещаться

Это Отмазы

Если что то не влезает в экран то его структура говно

в ФП это прописной истиной считается

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

это новая мода

Это не новая мода, это в хаскель пришли практики

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

"Практики" means джависты? Я, конечно, не хочу ничего плохого про джавистов сказать, но такая монополизация практики мне не нравится

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

Ну я вот не джавист но мнение по переменным у меня "до 20 символов норм, 30 на грани"

точно, вместо однобуквенных названий надо названия вроде таких. типТутОченьОбщийНичегоНеПридумываетсяАЧтоДелатьМыЖеПрактикиТакЧтоПРиходится

точно, вместо однобуквенных названий надо названия вроде таких. типТутОченьОбщийНичегоНеПридумываетсяАЧтоДелатьМыЖеПрактикиТакЧтоПРиходится

Чем более общий случай тем проще на самом деле :)

точно a называешь и все

Если тип выразитилен то переменную можно назвать так же и нет проблем

ну вот как тип обычно и называют a, b, m, f

Собственно, на этом уровень абстракции в джаве и кончается

ну a b m f это просто соглашение

переменную типа f можно назать functor, какие проблемы?

например в том, что это не функтор?

тогда зря ты назвал тип f

нет не зря, для него же есть инстанс класса функтор

но он не функтор

интересно

мне уже нравится твой код :)

"не понимаю типы, но спешу напрыгнуть на чей-нибудь код"

действительно не понимаю как инстанс класса функтор может не быть функтором

или ты про то что функтор это преобразование а не его результат?

не про это

ERROR: S client not available

тогда зря ты назвал тип f

Предлагаю угадать типы по названиям: b l c

и параметру который принимает инстанс класса функтор вообще не дать имени - он неявный, выше написано "для него есть инстанс класса функтор"

Предлагаю угадать типы по названиям: b l c

b и c - forall, l - зависит от контекста

b и c - forall, l - зависит от контекста

b - borrower c - consent (borrower digital consent) l - loan

Поэтому я не использую однобуквенные переменные, разве что как индексы в циклах

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

> но хаскель это не сишарп и?

почему вечно всплывают языки которыми на которых я не писал в качестве примера "это делают только там"?

почему вечно всплывают языки которыми на которых я не писал в качестве примера "это делают только там"?

А почему вы не писали на сишарпе?

потому что у меня нет OS Windows

дорого :(

потому что у меня нет OS Windows

И 15 лет назад не было?

15 лет назад мне было 10

А, ок.

я предпочитал C

попробую обяснить что тут не так: вот у нас есть map :: (a -> b) -> [a] -> [b] мы в него функцию передаем назовем ее тип как-нибудь type Func a b = a -> b map :: Func a b -> [a] -> [b] ну вот говорить что a - это Func a b потому что мы можем применить ее к а примерно столько же оснований, что и говорить что f это Functor

ты ведь понимаешь, что если следовать аналогии то первый параметр нужно назвать function?

чем он определенно является

Зачем дублировать информацию? Чтобы потом путаться, после того как сигнатура поменяется?

Венгерская нотация какая-то

тут-то все нормально это же функция. по аналогии с называнием f functor надо называть a - funcab map :: Func funcab b -> [funcab] -> [b] а, нет map :: Func funcfuncabb b -> [funcfuncabb] -> [a] а, нет

то есть мы хотим менять сигнатуру не меняя внутрености функции?

Конечно

внутренности то тут причем?

> по аналогии с называнием f functor надо называть a - funcab где аналогия то?

lpcstrzWindowTitle и прочие hwndpnWindowParamName

lpcstrzWindowTitle и прочие hwndpnWindowParamName

Это как раз про вышеупомянутый Си

тоже практики писали

Конечно

мне кажется весьма редкий кейс когда это возможно

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

ну перестановка аргументов местами очевидно в любом случае делается без правки кишок

тоже практики писали

это разве не особенности полиморфизма в C?