the alternative is learning what hoisting and a te...

# arrow

[pakoito]

the alternative is learning what hoisting and a temporal dead zone is when moving to Javascript, how a CoroutineScope and CoroutineErrorHandler interact together in Kotlin, what @asynccontextmanager does in Python, decipher what function of CompletableFuture corresponds to mapping a value, or how to safely compose Futures in Scala

[jimn]

"Pure functional" that moved me decades ago was c++ templates, for which the execution became a gaming of the compiler which was legal but not entirely planned by its creator. https://softwareengineering.stackexchange.com/a/336895
since the moment I understood template metaprogramming and began conceptualizing thier advantages (now less impact due to link-time optimizers) programming languages have all really kind of underwhelmed, except specifically for definition languages of grammars, which are the meta of programming languages. for me the measure of a programming language's overall conciseness shows up when you use to extend or build a new grammar that can share the existing parent's metamodels.

[jimn]

FactorLang represents about as much of a 180 as you can achieve coming from imperative. it proves that there are hyper-efficient representations and modalities outside of right to left stack assignment, which is actually backwards to the underlying object code emitted.
My point is not that I want to debate Factorlang in a kotlin forum conversation, but that I think Kotlin would be impressive, would carry the "pure functional" torch, by accomodating extensions to its grammar, even perhaps to its parse assumptions. Arrow is as close as I've seen to treating kotlin as more than simply a lombok++

[jimn]

To be able to tweak the grammar inline, or shift modalities to fit a problem, that's something harshly capped in kotlin, basically just slightly more terse java.

[pakoito]

We’re working on compiler extension that add semantical constructs, and not syntactic ones. Syntax is at a good crossroad between industry and FP goodies: extfuns, lambda parameters outside (), default parameters, receiver functions

[pakoito]

on the syntactic side, we can make optional parameters inject global typeclasses, use coroutines to model comprehensions/do notation, and delegates to replace binding. Maybe other stuff in the future

[pakoito]

I will need to spend time learning what Factorlang is, I must confess that I didn’t stop to read about it before replying

[pakoito]

These are the killer platform

Kotlin’s killer app is Android. Being a Nicer Java 6 is a small plus on backend, where they have access to Java 12+ or Scala if they wanted to.

[pakoito]

The language is marketed at the career Java developer, which appeals to organizations as well.

[jimn]

thank you for examining Factor, the video is a pretty concise exposure which is all I meant by introducing it. The author is giving talks about different languages these days, so it demonstrated what it needed to at the time for his own career mobility--he was the author of JEdit fwiw.

[jimn]

what Kotlin is enabling is something like a c# port to llvm/jvm/js imho. even if you can do things with ;-) symbols and a few more than a dozen operator overloads, going right to left, you still need to write a new program to parse a new grammar, and thereby you have to individually wrap the ecosystem features you want to keep in yet another binding layer [if you are fond of other grammars and Kotlin benefits]. with Arrow-kt and a compiler plugin you are holding onto the ecosystem and prioritizing the inclusion of the <Special sauce above> i guess to demonstrate or diverge with directions in Kotlin 1.x. so even if I am agnostic to Arrow-kt, you may be exemplifying methods of introducing new expression formats into kotlin compilation that I can run with.

[jimn]

i don't have any disgreements with Arrow-kt, btw, though I do view the occasional intros at project junctures when deciding how to proceed for various coding approaches, but ultimately have never had a likely candidate for arrow-kt refactorings or code that would reduce technical debt through Arrow.

[jimn]

my current Juncture is one where i am using python pandas, not because I have anything good to say about it, but because the ecosystems i need are python, the examples are python, and the kotlin equivalence is lacking while the ecosystem would be ideal to have. building a kotlin compatible syntax for pandas might or might not move the needle, but Pandas is simply a working collection of libraries and choices of [python] operator overloadings that have gained a following wrapping numPy - something kotlin native would not need to do.

[jimn]

From a technical debt perspective, enabling a Pandas grammar in kotlin could borrow Arrow-kt's precedent, but could also benefit from actually enabling Arrow-kt intrinsically from what i know to curb some nits. but for a minor increase in technical debt beyond that, I feel like a potential end-game metaprogramming grammar extension facility could bring almost any grammar ( using Factor as a benchmark for /very/ different) to the kotlin ecosystem. I believe that could more than move the needle, and influence platform decisions for ongoing tooling evolutino like pytorch and tensorflow (the career thing)

[jimn]

at a certain technical debt for construction, i imagine that the equations being converted to imperative code could be preserved in less programmatic mid-points, or we could potentially just use a latex equation description to down-translate through compiler extension iterations to achieve more transparency with metaprogramming that shares the compiler with the rest of the kotlin ecosystem