@haskellru

Страница 780 из 1551
Alexey
26.01.2018
21:25:26
я не чтобы посраться

просто для себя понять

да я не думаю на хаскел наверное

просто

Google
Alexey
26.01.2018
21:26:10
язык классный

эльм классный

Aleksey
26.01.2018
21:26:17
Ну так то и про хаскелекод нельзя сказать, что он ссостоит строго из обобщённых решений.

Alexey
26.01.2018
21:26:28
смотри

Aleksey
26.01.2018
21:26:29
Elm - полярно инаков

Alexey
26.01.2018
21:26:35
простой вопрос

надо ли

думать

над дженерик решением

если есть тупое?

Aleksey
26.01.2018
21:27:23
В Elm все программисты - тупые. За них надо решить всё и упаковать в "Архитектуру". А самим возможности выходить за рамки не давать. Решение сугубо политическое

Дмитрий
26.01.2018
21:27:33
надо ли
Тут как с рефакторингом, делаешь один раз, нафг не нужно, два - задумываешься. Три - ищещь обобщение.

Но это моё мнение.

Google
Aleksey
26.01.2018
21:28:07
Если есть тупое решение в приложении - используют тупое. Если есть возможность+необходимость обобщить в либу - обобщают. Всё как у всех

Бывает, что тупое потом генерализуют. Половина (больше?) либ так и родилась

Alexey
26.01.2018
21:29:22
ну вот смотри, я уже лет 15 в программировании

Aleksey
26.01.2018
21:29:31
И генерализуют то потому, что не уверены, что в следующий раз напишут правильно

Alexey
26.01.2018
21:29:34
не помню чтобы мне надо было переделывать

суппортить сложно - да

Aleksey
26.01.2018
21:29:42
Я 20+ лет в программировании :)

Бывало, переделывал

Alexey
26.01.2018
21:30:02
ну охуеть теперь -)

Aleksey
26.01.2018
21:30:11
Меряемся дальше!

Alexey
26.01.2018
21:30:30
да нет цели такой

я же сказал

я просто в поисках

более высоких абстракций

Aleksey
26.01.2018
21:31:02
Я понимаю, что излишняя забота о том, чтобы "было максимально абстрактно" - не слишком продуктивна порой

Alexey
26.01.2018
21:31:07
но блин хаскел разочаровал

но другого ничего нет

Дмитрий
26.01.2018
21:32:00
Alexey
26.01.2018
21:32:03
хотя

нене

Google
Alexey
26.01.2018
21:32:11
Dotty

выглядит прикольно

Aleksey
26.01.2018
21:32:39
Я понимаю, что излишняя забота о том, чтобы "было максимально абстрактно" - не слишком продуктивна порой
Но тут есть один пункт: в хаскеле очень много маленьких композируемых решений. В противовес фреймворкам всё-в-одном в других языках. Такие многообразие и композируемость достижимы именно через "подумать над аобстракцией"

Дмитрий
26.01.2018
21:32:39
А у нас пока дже зависимых типов нет, года до 20-го где-то.

Как мы только без них живём?

Alexey
26.01.2018
21:33:07
Не не смотри

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

Ну типа там теория категрий и все такое

и вот эти штуки типа

Int | Double

классно же? -)

Aleksey
26.01.2018
21:33:57
Нет

Alexey
26.01.2018
21:34:06
Почему?

Aleksey
26.01.2018
21:34:10
Either Int Double - у нас так пишут :)

Alexey
26.01.2018
21:34:24
Изер - костыль

Aleksey
26.01.2018
21:34:41
Это явная сумма. А Int | Double - первый шаг к Any

Alexey
26.01.2018
21:35:07
хоспадя я и без хаскеля это напишу

Дмитрий
26.01.2018
21:35:25
Either Int Double - у нас так пишут :)
Семантика же другая... Изер - это средство обработки ошибок.

Alexey
26.01.2018
21:35:27
хаскель это вообще абстракция

идельный язык

Google
Aleksey
26.01.2018
21:35:48
Семантика же другая... Изер - это средство обработки ошибок.
Нет, конечно. Это сумма общего назначения

Alexey
26.01.2018
21:35:52
обработка ошибок просто частный случай

надо же думать об типах как об математических типах

ну хотя бы приучить себя уже -)))

Дмитрий
26.01.2018
21:37:30
надо же думать об типах как об математических типах
Именно по этому я пишу шаблонами типы описывающие пересекающиеся множества, да.

Alexey
26.01.2018
21:38:09
`

Дмитрий
26.01.2018
21:38:13
И шаблонами генирю класы и инстанцы для работы с ними, чтобы не видить тот ужас, что нагенирился под копотом.

Alexey
26.01.2018
21:38:16
public class Either<X, Y> { private final Optional<X> x; private final Optional<Y> y; public Either(X x, Y y) { this.x = Optional.ofNullable(x); this.y = Optional.ofNullable(y); } public static <X, Y> Either<X, Y> of(X x, Y y) { return new Either<>(x, y); } public void apply(Consumer<? super X> xFn, Consumer<? super Y> yFn) { x.ifPresent(xFn); y.ifPresent(yFn); } public <T> T map(Function<? super X, ? extends T> xFn, Function<? super Y, ? extends T> yFn) { final Optional<T> t1 = x.map(xFn); final Optional<T> t2 = y.map(yFn); return t1.orElseGet(t2::get); } }

ну вот так хотя бы

уже както себе лучше жить

Admin
ERROR: S client not available

Aleksey
26.01.2018
21:38:54
Вот! Смотришь на такое и понимаешь, Haskell гораздо приятнее даже тупо синтаксически

Пойду спать на этой радостной ноте

Alexey
26.01.2018
21:39:08
!

снов хороших тебе

без джавы -)

Aleksey
26.01.2018
21:39:23
Спасибо :)

Java тоже к лучшему стремится. Я даже рад за неё

Дмитрий
26.01.2018
21:39:45
И то верно :)

А какой пакет из недавнего вас приятнее удивил?

Google
Alexey
26.01.2018
21:40:27
Я переписывать ее вот на проекте стал потихноьку -)

Дмитрий
26.01.2018
21:41:12
Вот по принципу, а вот прикольная фича, надо бы куда-то впихнуть.

Или почему я раньше такое не использовал!!!

Alexey
26.01.2018
21:41:38
не пизди

Leonid
26.01.2018
21:42:19
не пизди
у нас не матерятся

Alexey
26.01.2018
21:42:29
ща юзкейз найду

final CompletableFuture<Either<Throwable, CurrentlyConsumption>> response = client.request(); final Either<Throwable, CurrentlyConsumption> either = response.get(); either.apply( error -> assertTrue(true), success -> assertTrue(false) );

во

сырая джава

уродско конечно

просто type inference нет



вот из реального проекта

копипаста

да, не хаскел

вот из кровавого энтерпрайз вот

делаем софт для авиазаводов в швеции

Kit
26.01.2018
21:51:59
прикольно, как у нас в чатике уже прям даже код показывают, жаль что не хаскельный

Leonid
26.01.2018
21:52:08
ява какая-то

Alexey
26.01.2018
21:52:46
сам ты ява

ты удивишься

но ООп это не про ООп

Страница 780 из 1551