3 ms·

Maybe I'm just too inexperienced, but I don't see the point of this library. The linked example shows a really basic sqlalchemy model lookup. What does spewing

Maybe I'm just too inexperienced, but I don't see the point of this library. The linked example shows a really basic sqlalchemy model lookup. What does spewing these new types all over my code get me that returning None or an empty dict/list doesn't without the overhead? def find_user(user_id: int) -> Optional[User]: user = User.objects.filter(id=user_id) if user.exists(): return user[0] else: return None Not only is this idiomatic, it conveys the same semantic meaning. I'm using an IDE, as is anyone else working in a large codebase. I'll be told at the point of invocation that find_user could return None and I need to possibly deal with that.

dragonwriter 5y ago
> Not only is this idiomatic, it conveys the same semantic meaning No, it doesn’t. For a single computation like this, that pattern is roughly equivalent to Maybe (which contains no information about the case where there is no success result besides that it is absent) rather than Result (which has error information, kind of like an exception, but in the normal return path.) For a series of computations, the composability of both Maybe and Result means that they are semantically richer.
- Karunamon 5y ago
  Couldn't I just return a tuple instead if I wanted to give the caller information on the nature of the success or failure? Also, both Django and SQLAlchemy throw proper exceptions on bad queries or DB errors, which is probably the right thing to do in the average app using these libraries (the exception bubbles up, getting logged, returning the appropriate http error, etc). I'm not crapping on this library, mind, I just can't find the use case that justifies it.
  - linkdd 5y ago
    It's about function composition. How do you compose a function that returns an int or an error with a function that takes an int as parameter? Yes you can split this in multiple steps, or you can use monads to handle the composition for you, making you type less code, giving more information to the typesystem (mypy for python for example) about what is valid and what's not. This is a completely different programming style, it's functional programming, aka: "how to make functions by composing other functions".

dragonwriter 5y ago

> Not only is this idiomatic, it conveys the same semantic meaning No, it doesn’t. For a single computation like this, that pattern is roughly equivalent to Maybe (which contains no information about the case where there is no success result besides that it is absent) rather than Result (which has error information, kind of like an exception, but in the normal return path.) For a series of computations, the composability of both Maybe and Result means that they are semantically richer.

Karunamon 5y ago
Couldn't I just return a tuple instead if I wanted to give the caller information on the nature of the success or failure? Also, both Django and SQLAlchemy throw proper exceptions on bad queries or DB errors, which is probably the right thing to do in the average app using these libraries (the exception bubbles up, getting logged, returning the appropriate http error, etc). I'm not crapping on this library, mind, I just can't find the use case that justifies it.
- linkdd 5y ago
  It's about function composition. How do you compose a function that returns an int or an error with a function that takes an int as parameter? Yes you can split this in multiple steps, or you can use monads to handle the composition for you, making you type less code, giving more information to the typesystem (mypy for python for example) about what is valid and what's not. This is a completely different programming style, it's functional programming, aka: "how to make functions by composing other functions".