A modern programming language that makes developers happier.

kotlinlang

the recording of my talk about the state of the ecosystem in Sept 2019 is available now: <https://twitter.com/pacoworks/status/1184090662779674632>

Hi Paco, thanks for the talk!

I just watched the recording and then think whether would it be helpful to list down the papers referenced by Arrow in the doc. That may help to build a greater context of why something looks like the way it is in the library

can we get any more specifics about "stop ****ing up our language" from the kotlin lang developers?  this is the impression i get when i watch the language discussion unfold -- the two major responses seem to be "We did it this way and we're OK with that", and "maybe this has some upsides but we think the users could excercise antipatterns if we allow that."

<@U65FK6QNB> don’t read too much into it. It was years ago and it wasn’t on bad faith.

<@UHQV5N82H>

Frank: <http://homepages.inf.ed.ac.uk/slindley/papers/frankly-draft-march2014.pdf>
Lightweight Higher-Kinded Polymorphism: <https://link.springer.com/chapter/10.1007/978-3-319-07151-0_8>
Build Systems a la Carte: <https://www.microsoft.com/en-us/research/publication/build-systems-la-carte/>
Selective Applicative Functors: <https://icfp19.sigplan.org/details/icfp-2019-papers/27/Selective-Applicative-Functors>

thanks <@U0B8UEMV1> I'm not looking for skelotens I am looking at an endgame -- I "think" there is lattitude to use the compiler extension infrastructure to go for transformative endgames where it's not intended or endorsed presently.  I think that even "bend not break" is more than the kotlin-lang agenda has patience for.  kotlin is kotlin, and being matured.   your comment above and the timeframes involved suggest it's not a showstopper.

if kotlin isn't a showstopper for more than minor extensions, despite google/android momentum anchoring it, I can justify this as a direction for more research and resources where I'm at now.

iiuc Arrow-kt is the example to look at for coloring outside the lines

honestly OOP and type declarations supported by an OOP language are far less practical debates than the energy spent in pros and cons of going with an ORM or postgresql classes or a json persistence layer.  scale doesn't happen at the type declaration level.

im keen on data manipulation.  this is not addressed significantly in language/FP discussions.

&gt;transformative endgames where it’s not intended or endorsed presently.

Google is doing Compose/React, which is very transformative and transformation-heavy. I wouldn’t say it isn’t endorsed, as much as just having responsible stewardship for it

<@U0B8UEMV1> thanks. should i create a pull request to add them to the doc?

To what doc? Only Frank and the Lightweight ones are used in the design.

thought it may also help others if we put those links onto the arrow doc

it’s a good idea. Where do you propose they should go? Glossary? Projects?

maybe somewhere like credits? <https://arrow-kt.io/docs/legal/credits/>

even though it may have nothing to do with "legal"