hello guys first of all thanks so much for all the...

# arrow

[Bruno]

hello guys first of all thanks so much for all the effort around arrow, I can feel the energy so to say! I am invited to give a presentation in austria / vienna on "functional programmng with arrow" in late january and I am bit lost with all the changes happening right now (deprecation of adts, arrow-fx, arrow-meta, ...). I can embrace that arrow tries something completely new that does not exist in other languages... which is really cool don't get me wrong. I have a hard time learning arrow myself and I noticed that the little knowledge of fp coming from elm/haskell (or having and rough idea about maybe, either, adts, which are now deprecated, folds etc.) and the little knowledge of kotlin don't really help me out in learning the idiomatic arrow way of fp that is being created right now ... Learning arrow feels more like learning a completely new language (which is fine for me!) compared to e.g. the transition from java to kotlin or learning elm after haskell. I say this because I anticipate that the people I am going to present to will also need very basic and example driven introduction to arrow ("how do I do x with arrow?"), because most of them are even new to functional programming. I try to imagine how this could be done, using my challenges right now as valuable information. So having a hard time coming up with a very concrete question I want to broadly ask: What does a idiomatic arrow program look like? Why do I raise such a question? Because I watched the very polished arrow youtube videos (thanks for the effort) but I unfortunately didn't get a feel of how I was supposed to program with them. Since I knew Option, Either, etc. from before I knew how to apply them, but using them didn't really feel like I am using the the possibilities of arrow in the intended way. So not the pieces but seeing them used together was what I was missing there. So my proposal is that if someone could pair up with me to get me started on putting such kind of examples together then I can keep going on my own doing that for other people that need some examples to get them started ... sorry for the long post! hope to hear from any of you

[Jannis]

With regards to the changes coming up: I'd suggest to stick with what currently exists and wait till union-types and in general the compiler plugins are stable with some documentation surrounding it. The concepts that currently exist will still carry over and even if partially obsolete will make learning new concepts much easier. For examples of arrow in action, I can't help that much with that atm (too many things, too little time 🙈). I'm sure others can jump in tho, also feel free to just ask about anything that confuses you when reading docs/writing code, we are always eager to help (and those question might lead to improved docs!)

[Bruno]

Thanks for the reply and I totally understand, hope someone else has time

[pakoito]

I believe @simon.vergauwen or @raulraja may find the time, or me if it’s in a couple of weeks from now 😄

[Bruno]

cool that'd be awesome, when and how should I get back to you !? btw just watching your talk: Stop ****ing up our language", porting the FP stack to Kotlin

[raulraja]

@Bruno I can give you a walkthrough on all that is happening that may impact your talk

[raulraja]

We can do a hangout and I can show what we are doing in meta and arrow for 2020 and give you branches you can monitor for progress

[raulraja]

There are several people working full-time on it to make it happen in 2020 for the best FP experience in Kotlin and IDEA

[Bruno]

Nice lets do this. I would really like to contribute something back and also make arrows strengths become apparent in my presentation

[Bruno]

So when is the best time to reach out to you?

[raulraja]

Sometime tomorrow between 12pm - 5pm (GMT+1) works for me. I’ll be with other Arrow people in the room which can benefit from the walkthrough on the upcoming most important features and vision for 1.0. It will be an internal conversation and I plan on just showing some code examples and answering questions. Anyone else is welcome to join if it works for them. I will post link to the hangouts once we know the time.

[jimn]

i sat down to annotate one of the youtube presentations from July - annotations and video at...

https://www.youtube.com/watch?v=uyqqoooKpmI&lc=UgxYVFk4CGJ389AAx2J4AaABAg▾

It doesn't appear clear to me where Kotlin fails to provide the features that Arrow is emphasizing, and I feel like I know too much kotlin muscle memory to re-orient my thiunking around slightly less direct ways of doing the same kotlin things; personally. annotating the features as above has helped me understand the intent of the 2019 summer state of arrow-kt

[Attila Domokos]

Can you please record that conversation? It would be great to see it (unless it's confidential).

[jimn]

come to think of it there's a lot of offers to help and a lot of announcements but the before and after comparisons have been light in here, since I have been lurking.

[jimn]

this brings to mind the blissful productivity of a perl programmer, and the stark contrast of understanding how they solve a given problem with "more than one way to do things" at their disposal.

[raulraja]

@Attila Domokos It’s not confidential but we don’t record conversations because it requires explicit permission of everyone and it’s not something I’d like to deal with but all this info is also coming through official channels as it becomes available. Also as I’m showing experimental lang features I don’t want the video to be taken out of context because many of these features will not make it as shown there

[raulraja]

@jimn Not sure with what you mean with before and after. If you mean Arrow as it now vs what we want it to be we are all still discovering that.

[Attila Domokos]

I understand. I'd be happy to be the fly on the wall during that convo, though.

[raulraja]

There is definetly more than one way to do things in Arrow and that is what we are solving as we approach 1.0

[raulraja]

deprecating APIs and making unpopular decisions like killing Try xD

[jimn]

@raulraja i can look at a growing list of documented features and types but what im saying is that for better or worse, is that in the taxonomy of a 20 line json parser, for example or the proverbial todo app, we're not being lead to the before and after picture that highlights the arrow-kt payout/benfit/wow factor, so it becomes a dedication for the reader to try to grasp the available Arrow features with less context tying back to the common problems. i get that side-effects are flagged by suspend, and there are 4 parent trees of how to line them up and knock them all down, but honestly i only have a few minutes of one talk to digest that alludes breifly through the important points along side some of the less interesting points.

[raulraja]

makes perfect sense and I agree

[raulraja]

We have a dedicated team for the site and docs in 2020 that have already started reviewing content

[raulraja]

In the mean time feel free to suggest any ideas for improvements as issues

[raulraja]

I dislike the current state of docs but it’s only natural given so many different people have contributed in spots at intervals

[raulraja]

We hope this is gonna change in 2020

[jimn]

the benchmark distributed app is a pet shop with a database, though generally out of scope for 5 line examples but not entirely irrelvant for actor-based scenarios. for something a little smaller the benchmark is todo with perhaps a little bit too much emphasis on MV[PC]+, or more recently HN feed readers. for me it's zero-copy IO and json parsers are the perfect size. im not able to be dedicated to the site and docs, so im lurking, and tuned into the novice programmers with very basic scenarios to enumerate better approaches

[jimn]

if anything there are clearly too many areas of differentiation and a 45 minute talk is insufficient to do justice, even though attention span is far less. println moved to suspend is a decent example [of FX]. what may move the needle is management ammo-- common imperative antipatterns, collapsing spaghetti code is always a useful and relevant painpoint to inform the decision-makers of working smarter (than the race to the bottom of the javascript programmers on ubid)

[jimn]

if i could get more traction via the simple examples, and I am clearly not alone, i would have a lot of energy, and I am already quite motivated to contribute as well as influence a large under-represented part of Asian developing tech culture. I'm not identifying enough clear wins to reprioritize the coding habits I use now as an influencer. my kotlin is adequate to chip away at my python dominated workload, but I haven't spotted the right catalyst nothing like "that first time I ran gson serializer!" a decade ago.