К каким именно словам ты хотел бы придумать контрпример?

Нормальной внятной мысли почему maybe это плохо. Мне может реально интересно, почему Но из всего диалога я вынес только то, что ты попрбовал и тебе не понра Теперь мне придётся с этим как-то жить

Ну а это не то, чтобы кого-то сильно сейчас интересует.

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

mst оооочень медленный

"Настраивал вебпак". Лол.

для моих кейсов

mst оооочень медленный

О как

Вдвойне фигово(

ну у меня риалтайм и модели жирные

2 Гб и 133% цпу ест

?

Сурово

Опять короче велосипедить по ходу

вообще такое ощущение, что проверки не все в прод билде отключаются

Ох щи

// TODO: this test still needed? ... Object.freeze(this.properties) // make sure nobody messes with it Конструктор модели

Нет. Ни за чем он там не нужен. Можно абсолютно спокойно и безболезненно обойтись без него.

Именно поэтому в восьмой джаве появивился Optional, ведь они спокойно безболезненно работали с Null pointer exception

Нормальной внятной мысли почему maybe это плохо. Мне может реально интересно, почему Но из всего диалога я вынес только то, что ты попрбовал и тебе не понра Теперь мне придётся с этим как-то жить

Ну, смотри, во-первых, я не утверждаю, что Maybe — это плохо. Я утверждаю, что если ты будешь писать коммерческий код с использованием maybe, то это приведет либо к а) чрезмерно запутанному коду, либо к б) продалбыванию сроков проекта. Ну, банальный пример. С сервера нам приходит модель: setState({ name: 'John Doe' }); Пишем обработчик формы с Maybe: <input type="text" defaultValue={this.state.name} onChange={(event) => { const value = Maybe(event.target.value); this.setState({name: value}); // WTF? this.state.name будет иметь два типа: String из JSON-а, и Maybe, потому что мы его туда положили. }} /> Придется доработать форму: <input type="text" defaultValue={isMaybe(this.state.name) ? this.state.name.value() : this.state.name} onChange={(event) => { const value = Maybe(event.target.value); this.setState({name: value}); }} /> Спрашивается, нафига так делать, если и без этого все прекрасно работает?

Именно поэтому в восьмой джаве появивился Optional, ведь они спокойно безболезненно работали с Null pointer exception

Не. Если это поддерживатеся на уровне платформы — базара ноль. Абсолютно ничего не имею против нативных промисов, или Option в rust-е.

Полагаю, в жс тоже скоро может появиться .? Это не то, но все же шажок

Ну, смотри, во-первых, я не утверждаю, что Maybe — это плохо. Я утверждаю, что если ты будешь писать коммерческий код с использованием maybe, то это приведет либо к а) чрезмерно запутанному коду, либо к б) продалбыванию сроков проекта. Ну, банальный пример. С сервера нам приходит модель: setState({ name: 'John Doe' }); Пишем обработчик формы с Maybe: <input type="text" defaultValue={this.state.name} onChange={(event) => { const value = Maybe(event.target.value); this.setState({name: value}); // WTF? this.state.name будет иметь два типа: String из JSON-а, и Maybe, потому что мы его туда положили. }} /> Придется доработать форму: <input type="text" defaultValue={isMaybe(this.state.name) ? this.state.name.value() : this.state.name} onChange={(event) => { const value = Maybe(event.target.value); this.setState({name: value}); }} /> Спрашивается, нафига так делать, если и без этого все прекрасно работает?

Э, работать с мейби намного проще.

Ну, смотри, во-первых, я не утверждаю, что Maybe — это плохо. Я утверждаю, что если ты будешь писать коммерческий код с использованием maybe, то это приведет либо к а) чрезмерно запутанному коду, либо к б) продалбыванию сроков проекта. Ну, банальный пример. С сервера нам приходит модель: setState({ name: 'John Doe' }); Пишем обработчик формы с Maybe: <input type="text" defaultValue={this.state.name} onChange={(event) => { const value = Maybe(event.target.value); this.setState({name: value}); // WTF? this.state.name будет иметь два типа: String из JSON-а, и Maybe, потому что мы его туда положили. }} /> Придется доработать форму: <input type="text" defaultValue={isMaybe(this.state.name) ? this.state.name.value() : this.state.name} onChange={(event) => { const value = Maybe(event.target.value); this.setState({name: value}); }} /> Спрашивается, нафига так делать, если и без этого все прекрасно работает?

Код с maybe вообще не нужно проверять на isMaybe fromNullable(event.target.value) .map(name => this.setState({ name }))

Полагаю, в жс тоже скоро может появиться .? Это не то, но все же шажок

Ну, вот если/когда появится, тогда и можно будет всерьез подумать. В JS-е довольно много вещей, которые так и не были по-настоящему восприняты сообществом.

Ты прав в том, что подключать maybe а потом всё обмазывать проверками на isMaybe — это шиза

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

Ты прав в том, что подключать maybe а потом всё обмазывать проверками на isMaybe — это шиза

Ну, типа, суть то от этого не меняется. Делать на любой чих fromNullable из той же серии.

Ну, смотри, во-первых, я не утверждаю, что Maybe — это плохо. Я утверждаю, что если ты будешь писать коммерческий код с использованием maybe, то это приведет либо к а) чрезмерно запутанному коду, либо к б) продалбыванию сроков проекта. Ну, банальный пример. С сервера нам приходит модель: setState({ name: 'John Doe' }); Пишем обработчик формы с Maybe: <input type="text" defaultValue={this.state.name} onChange={(event) => { const value = Maybe(event.target.value); this.setState({name: value}); // WTF? this.state.name будет иметь два типа: String из JSON-а, и Maybe, потому что мы его туда положили. }} /> Придется доработать форму: <input type="text" defaultValue={isMaybe(this.state.name) ? this.state.name.value() : this.state.name} onChange={(event) => { const value = Maybe(event.target.value); this.setState({name: value}); }} /> Спрашивается, нафига так делать, если и без этого все прекрасно работает?

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

Это я тебе как человек, который писал довольно много кода с Promise.join.

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

.map

.chain

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

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

Ты пытаешься приделать новую концепцию к старым повадкам, это так не работает

Лол

Ты пытаешься приделать новую концепцию к старым повадкам, это так не работает

Лолшто?

Я как вспоминаю старый свой гошный код с десятком if err на функцию, так седею. Го абсолютно точно нужен ейзер, можно и встроенный. Вспомнил про него, когда начал писать пример на жс с мейби

Я как вспоминаю старый свой гошный код с десятком if err на функцию, так седею. Го абсолютно точно нужен ейзер, можно и встроенный. Вспомнил про него, когда начал писать пример на жс с мейби

Это у тебя скорее всего, в том, что ты писал в структурном стиле. Множество if-ов в коде говорят о том, что у тебя много вызовов на разных уровнях абстракции.

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

Читать дядюшку Боба.

Нет, там простая каждая функция вернуть ошибку, нужно все обработать

В этом коде 11 проверок на null

Это elm?

Это у тебя скорее всего, в том, что ты писал в структурном стиле. Множество if-ов в коде говорят о том, что у тебя много вызовов на разных уровнях абстракции.

нет, ты просто го не видел ;)

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

Это elm?

purescript

Вспоминается LiveScript.

У кого какие аналогии

Го

Я вообще не понимаю смысла этого кода. Судя по всему, тут не в Maybe дело.

А теперь самый момент напомнить про тупых фронтендеров

Судя по всему тут не в Maybe дело, да ?

Но вообще это довольно тривиальная конструкция, я типа учусь и всё такое

Ага. Совершенно точно диагноз поставил. Прям горжусь собой. У тебя в одной функции и запрос к серверу, и разбор ответа, и маппминг в объект и маршаллинг.

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

Но вообще это довольно тривиальная конструкция, я типа учусь и всё такое

Можешь в пяти словах описать что делают эти две функции?

Есть некая f, которая может вернет, а может не вернет значение. const a = f(1); if (a !== null) { const b = f(a); if (b !== null) { const c = f(b); if (c !== null) { doSmth(a, b, c); } } } Если мы заменим на Maybe вместо null и будем делать такие же проверки isMaybe, как ты предлагаешь, то ничего не измениться. Но есть ду-нотация, она же async/await для промисов в жс (только не так). const f = x => x === 5 ? just(5) : nothing(); //... const a = yield f(1); const b = yield f(a); const c = yield f(b); doSmth(a, b, c); В результате все проблемы (nothing) улетают во время выполнения yield-ов

Есть некая f, которая может вернет, а может не вернет значение. const a = f(1); if (a !== null) { const b = f(a); if (b !== null) { const c = f(b); if (c !== null) { doSmth(a, b, c); } } } Если мы заменим на Maybe вместо null и будем делать такие же проверки isMaybe, как ты предлагаешь, то ничего не измениться. Но есть ду-нотация, она же async/await для промисов в жс (только не так). const f = x => x === 5 ? just(5) : nothing(); //... const a = yield f(1); const b = yield f(a); const c = yield f(b); doSmth(a, b, c); В результате все проблемы (nothing) улетают во время выполнения yield-ов

Ну, смотри. Если у тебя такой каскад if-ов, это значит, ты пытаешься получить значение «низкого» уровля вложенности, т.е. на другом уровне абстракции. Скорее всего ты это делаешь совершенно зря, нужно по-другому. Maybe тут выступает в роли «дезодоранта», как выражается дядюшка Боб, но не решает проблему.

Scala: for { a <- f(1), b <- f(a), c <- f(b) } yield doSmth(a, b, c); Haskell (тут правда doSmth обязан мейби отдавать) do a <- f 1 b <- f a c <- f b doSmth a b c .

Монады собственно и решают проблему вложенности в общем случае, они m(m(x)) к m(x) сводят, это и колбеки (фьючерсы, промисы), и ифы (мэйби, ейзер)

Я просто довольно много писал кода с null-propagation-ом. И я вам могу сказать, что это лишь усугубляло ошибки.

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

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

Кароч, если объяснишь что этот код делает, я, может быть и смогу сказать как его улучшить. Сейчас я даже конструкций языка не понимаю.

Ага. Совершенно точно диагноз поставил. Прям горжусь собой. У тебя в одной функции и запрос к серверу, и разбор ответа, и маппминг в объект и маршаллинг.

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

Кароч, если объяснишь что этот код делает, я, может быть и смогу сказать как его улучшить. Сейчас я даже конструкций языка не понимаю.

Валидация входящих данных, большой глубоко вложенный json с кучей кейсов пошагово типизируется чередой вложенных чтений полей и выбору кейсов на основе результатов

Точнее не валидация, а часть классификатора данных

ERROR: S client not available

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

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

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

Что у тебя за pureJust, pure+join?

Вся фигня в том, что это самое начало, а дальше начнутся вложенные комбинации из-за которых я и решил написать на пурсе https://github.com/zerobias/telegram-mtproto/blob/feature/mtproto3/packages/mtproto-classify/src/Classify/Import.purs#L59

Валидация входящих данных, большой глубоко вложенный json с кучей кейсов пошагово типизируется чередой вложенных чтений полей и выбору кейсов на основе результатов

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

Что у тебя за pureJust, pure+join?

Ага, я интуитивно догадываюсь, что там много вздорных конструкций))

можно было просто вернуть значение без pureJust)

pureJust $ f x === f x )

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

Я очень долго пытался, поверь) Это просто классификация, а дальше ещё использование этой классификации +_-

можно было просто вернуть значение без pureJust)

??

Ага, я интуитивно догадываюсь, что там много вздорных конструкций))

А просто восходящим анализом проблему не решить?

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

А просто восходящим анализом проблему не решить?

Там даже расположение элементов не регламентировано, может быть один, может быть массив второго уровня, некоторые элементы могут быть ещё глубже, а чтобы было не оч скучно — некоторые объекты прилетают без тела, и это становится ещё одной категорией кейсов (х2)

То есть тебе эти листья ещё нужно найти

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

https://github.com/zerobias/telegram-mtproto/blob/feature/mtproto3/packages/mtproto-classify/src/Classify/Import.purs

Вот сюда смотрю.

можно было просто вернуть значение без pureJust)

Вспомнил, это что-то типа траверса было, Array Maybe a -> Array a

Монады можно не расценивать как обычные значения, их смысл намного больше. У тебя есть какой-то обычный мир вычислений, 5 функций подряд, все как обычно, это Identity-мир. Но мы можем писать код в Maybe-мире, это такой же мир, как и предыдущий, те же 5 функций, ты работаешь с данными как обычно, только каждая из 5 операций может выкинуть тебя из мира, то есть Maybe дает эффект прерывания выполнения кода в этом мире. Есть either, который то же самое, только позволяет нашему коду вылететь из мира с каким-нибудь сообщением. Есть promise, который позволяет нам писать обычный код, только каждая из функций может быть ассинхронной, хоть в нашем промис-мире мы этого не видим

Когда осознаешь, что монады - это такие отдельные миры поверх чистого мира с каким-то эффектом, то перестаешь писать x.isJust() ? X.valus : ...

Поэтому сложно не найти применение мэйби, а "не найти его")

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

Я так понимаю, что на JS-е это можно переписать примерно так: const smokeTest = (text) => JSON.parse(text, (key, obj) => { const tlType = lookupTLType(obj); let val, arr; switch (tlType) { case 'msg_container': { if ((val = obj.messages) && (arr = toArray(val))) { obj = messagesNormalize(arr) return pureJust(obj); } } case 'rpc_result': { return messagesNormalize(obj); } } });

Нет, lookup отдает Maybe

Там весь код работает в мире мейби, то есть если функция какая справа от <- вернет Nothing, то весь код прерывается и возвращается Nothing У тебя же никакой проверки нет. Хотя кейс просто ничего не сделает

Нет, lookup отдает Maybe

Ну, я предполагаю что раз это на js-е, то Lookup отдает строку или undefined.

Я вижу в коде два раза используется messageNormalize.

Ну, я предполагаю что раз это на js-е, то Lookup отдает строку или undefined.

toArray тоже отдаёт Maybe, как и остальные функции И это мы ещё даже к самой классификации не перешли, а код уже выстроился мутабельной лесенкой

Вот еще бы полноценну IDE под JS.

Webstorm же

Только медленный ппц

// toArray тоже считаем, что возвращает undefined если не удается привести к нужному типу. const smokeTest = (text) => JSON.parse(text, (key, obj) => { switch (obj._) { case 'msg_container': let arr; if (obj.messages && (arr = toArray(obj.messages))) { return arr.map(messageNormalize); } case 'rpc_result': return messageNormalize(obj); } });

Даже так, наверное. Я исхожу из предположения, что obj.messages может быть либо массивом, либо пустым значением, не объектом. Если я не прав, то прошу поправить. Тода так получится: const smokeTest = (text) => JSON.parse(text, (key, obj) => { switch (obj._) { case 'msg_container': return Array.isArray(obj.messages) ? obj.messages.map(messageNormalize) : undefined; case 'rpc_result': return messageNormalize(obj); } });