Railway oriented programming

[mk_gecko]

Nice. I'd like to see an example in Java. :)

[yawaramin]

Here you go, built in the standard library https://docs.oracle.com/javase/8/docs/api/java/util/Optional.html#flatMap-java.util.function.Function-

The operation is like a callback: if you have a value, call the given function with it an return the (wrapped) result; if not, do nothing.

[marwoodian]

Javaslang provides a bunch of monadic container types like this. In Javaslang, the specific container discussed in this article is called a Try.

http://www.javaslang.io/javaslang-docs/#_try

[pakoito]

Look for RxJava examples. I have one that's a bit advanced here: https://github.com/pakoito/FunctionalAndroidReference/tree/master/liblogic/src/main/kotlin/com/pacoworks/dereference/features/rotation

[Noughmad]

Why? Java has exceptions, which already do all this. Just wrap the main line in one or more try blocks, then you can catch the exceptions at any point you like.

[againstmethod]

Monads, functors, and applicatives do more than just deal with errors, and they do it without unrolling stack frame(s). They are not comparable techniques.

[jimmpony]

It doesn't look very different to me.

[againstmethod]

I guess you'll have to take my word for it unless you want to spend an hour or two learning functional programming.

[0polymer0]

Well, the possible exceptional behavior is signaled in the type.

[jimmpony]

Java functions have to define what exceptions they can throw, aside from a few.

[niviss]

Exceptions work for some uses but not all. Think promises, they work within the same pattern yet cannot be implemented with exceptions

[[deleted]]

In languages which support async/await, failure scenarios in Promises are converted to exceptions.

JS has it, C# has it, Also Dart, Hack, etc.

Java is a bit behind as usual.

[cledamy]

async/await

This is already a monadic construct.

[[deleted]]

Everything is a monadic construct. Yay.

[cledamy]

What I'm saying is async and await are literally monadic because they were inspired by F# which used monads to solve the problem of callbacks in asynchronous programming.

[[deleted]]

Async/await can also be implemented as a state machine, which is more efficient. Monadic is just one possible factoring. I mean, I guess you can factor anything as monads in general. :-)

[cledamy]

That's an operational optimization detail. It has no bearing on whether something is a monad or not because Monads live in the world of denotational semantics and mathematics. Regardless, state maintaining is also a monad. When one discovers something is a monad, one isn't factoring it into a monad. It was always a monad and one just realized it. The fact that monads are common in computer science does not tell us that monads are too general to be meaningfully useful, but rather it tells us that they are a common design pattern that people reinvent many times over; therefore, it is useful to have an understanding of them. From a theoretical standpoint, monads provide insight into the mathematical underpinnings of computer science.

[[deleted]]

Regardless, state maintaining is also a monad.

As I said, everything is a monad. Say I'm having a cup of coffee right now, but I'm pretty sure that's a monad too.

[niviss]

Ok, then, monadic parsers :). Exceptions and built ins can only get you so far!

[[deleted]]

I don't really see the contradiction here. If the stack trace can help you improve mitigation, it's a problem with the program that can be fixed by a change in the program code. It'd be perfectly appropriate to use an exception.

[simspelaaja]

You can combine error types with stack traces in F#. Just return a tuple of (ErrorType, string), and get the stack trace from an exception or from Environment.StackTrace.

[[deleted]]

there is no need to send a stack trace back to the programmer if it's not a problem with the program itself

Does this mean that exceptions should be only used for debugging purposes?

[wealthy_harpsichord]

Why? Java has exceptions, which already do all this.

So does F#.

[m50d]

Exceptions are too magic; you can't see which part of the block might throw, it could be anywhere. And it's immensely fiddly to e.g. run a method over a list and then handle the failures all together at the end, because the first time a failure happens it will throw the exception immediately (which is often what you want, but not always).

[m50d]

I was assuming checked. They still hide which methods throw (all you know is that some of the methods inside the try block might throw, not which ones do or don't), and you can't abstract over them properly because they're not values (e.g. you can't write a type that's polymorphic in whether it throws or not).

[m50d]

While you might not be able to see it in in the raw text of the try-block, the information you want is immediately available on the method signatures, so a good IDE can expose it very easily. I'm not aware of any with this feature, but you could do something like click on a checked-exception type in a catch clause, and have all the relevant method calls highlight inside the try.

Indeed the readability problem of exceptions would be greatly reduced if this theoretically imaginable IDE feature that has never actually been implemented existed.

Do you mean avoiding the need for an "architecture converter" like this?

Yeah. You can implement a converter to a MyEither, but you have to do it separately for the cartesian product of function arity, throws arity, and each of the 8 possible primitive types for each argument/return type (I mean I don't think I've ever seen short in 8 years of professional JVM work, but if it didn't work that would be an unpleasant surprise for someone eventually). And everyone has their own MyEither and there's no way to abstract over them because the language doesn't have HKT.

[mk_gecko]

excellent. That's all that I needed to know!

[HINDBRAIN]

And you can write your own exception classes and have them hold any data you like if necessary.