#Kotlin #design 谈这我就想到，绝句的 KV<Int Str> 和 [1 2 3].lets:"+$this" 的 Fn1<Int Str>
就是两回事，避免歧义
[1 2 3](Sum)
[1 2 3](Sum{*}) 才真正应该是函数调用
get(Idx)T 就应该是方括号
设计语言时要顾虑一致性，不能为了理论优雅，就抛弃语文美感

"a".mayAs<Int>?.Str !
(1~9)(Sum{+}.byStep )

(1~100 by 2~101) ( Sum{[a b]a+b } by: it%10 } )
vs

("a" as? Int)?.toString !!

(1..9).scan{A+B}
1..100.zip(2..101).reduce{a,b->a+b).groupBy{it%10}

复杂不一定坏，只要扩展性和性能上有优势
最开始我只是把 py 的缩进给了 Kotlin，但最后，我没有把新手可读性 放在考量里
- 'TR' T lets(:Fun1<T R>) = fn()
fun<T,R> T.lets(fn: T.()->R)=fn()
at N id= +0
val N.id get()=this+0
—
正则和DFA
说起来对同T 的多个 fun T.xx ，是可以像Scala那样用 implicit inline class ?
Scala的优点和败笔同时是implicit。不知道怎么评价，就像你提供了技巧，但没约定好写法

^ val by 可以用 provideDelegate()=ReadOnlyProperty 定义
你没有把defaultFn 传到非 inline 的 fun/var (如forEach {}? ) 里，所以不应该加 crossinline
{cross,no}inline 只是用来禁用函数式参数的ret跳转内联的

好奇在 nonlocal return@ 上， kt 是如何内联的，假如参数内联可以靠IR模板的话
很好奇 List<get T> 在Go里为何不存在

OOP是强求了继承关系，或许正常来看 'T'(T Num Sort) 才是List<Int>的类型
但我讨厌滥用接口trait，应该 type Num Sort
感觉py的渐有类型换成全局infer 会更快（？ TS 可能有(infer from usage)，但是作为IDE功能了

我喜欢用成员交、成员并 表达 union 和 intersection types
java里成员并对接口(&)有点用, 甚至能为 tuple实现Func
—
现在用GPT， 有时感觉编程语言是没必要逐个去学的

但其实语言也能简化问题，方便编程创作；微调时用中文写需求，就很烂
这种有方向特色的创作，是GPT暂时做不到的；目前我只写这种代码
—
#Java圈莫名其妙的不做代码复用，像 Logger 和 Repo 这样就可以依赖注入进去

但变量是应该由 abstract class 来声明 ，不应该留样板代码，否则要设计模式干啥？

Javaer 的设计模式，除了Builder这种解决语法贫瘠的，都是做了一半， 留了一半给人当CV boy
PYer 虽然又蠢又冗，但至少不会贩卖问题；它解决过的都没有什么复制粘贴和坑