My experience building a path-finding algorithm using Amber

[David Alayachew]

Hello Brian,

Thank you for the response!

> Thanks for the nice success story and the kind words.  A
> few comments:
>
> > Since all elements of this structure were either
> > sealed, a record, or an enum, that meant that my
> > domain of possible types (and thus, solutions) was very
> > bounded. That boundedness made reasoning about my
> > domain much easier.
>
> This is the power of "make illegal states
> unrepresentable".  By using the type system to represent
> only the valid states of your domain, code can focus on
> the happy path.

I see what you mean now. Yes, now that I think about it, exception cases
and trying to keep all the logic in my head was really me trying to juggle
too many unhappy paths, bogging down my development efforts until I am just
spinning my wheels. Having the weight off of my shoulders allows me to move
and think more freely and creatively. To my understanding, the ability to
"make illegal states unrepresentable" comes from the fact that Java now has
Abstract Data Types. That makes ADT's very powerful and something I should
start defaulting to when the situation allows it to, so that I can get all
of this freedom and ease of movement.

As for the rest of your response, I'll just address it all in total without
quoting.

Yes, I definitely agree. Without
pattern-matching/Data-Oriented-Programming/ADT's, even the pain points I
mentioned would be far worse. In fact, prior to using Amber features, I was
in the camp of using solutions 1 and 2 exclusively, since 3 was just too
complex and error prone to maintain in the face of refactoring or changing
requirements. It's only because of the thus far released features that 3
even became an option for me at all.

I am very excited for what this future with pattern-matching looks like. In
my previous attempt [1], I went down the painstaking route of getting my
data into fully strongly typed objects, so I paid the full price of
translation, as mentioned in the link. And I did exactly like you said in
my previous attempt -- I ended up with this >60 line mess of trying to turn
untyped data into typed data [2].

Can you give me a tiny snippet of what that future might look like? You
mentioned composing, and that makes a lot of sense, but I was curious about
what the things we are composing look like. You say we are composing
pattern matching. You mentioned matching the String in your example,
`"x":"3"`. I used an ugly java.util.regex.Pattern to handle a String of a
similar format in my previous attempt [3]. What might the future look like
when pattern matching that `"x":"3"`? I see that java.util.regex.Pattern
introduces sort of a second class citizen version of pattern matching right
now. You use Pattern::matcher to test for a match. And the only way to
extract the successful match is to call the Matcher::matches method first,
then extract. Java will return a failure if you do not call this first,
allowing essentially the same functionality that pattern matching gives
you. Are we going to see a more condensed and first class version of this
when turning Stringly-typed data into strongly typed data? And if so,
what's your guess of what that would look like?

Thank you for your time and insight!
David Alayachew

[1]=https://mail.openjdk.org/pipermail/amber-dev/2022-September/007456.html
[2]=
https://github.com/davidalayachew/RulesEngine/blob/main/src/main/java/io/github/davidalayachew/ClassParser.java#L22
[3]=
https://github.com/davidalayachew/RulesEngine/blob/main/src/main/java/io/github/davidalayachew/IsIdentifierAType.java#L9
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20230426/4b86c9a1/attachment-0001.htm>