#JavaEE #Java #web #backend #statement #dev

在我们完全无视软件需求的情况下，Java EE 看起来就像是无端制造复杂度[1]，从这一点上看起来，我觉得《Python 机器学习快速入门》这本书的作者对 OO 的观点是有点道理的。

（大意）

有人说“面向对象”最大的好处就是方便把人脑子搅乱。

Linux, Windows, UNIX, Mac OSX 的内核都是 C 语言、汇编写的，可唯独有一个操作系统不一样，就是 Nokia 的塞班系统，是用面向对象编程语言 C++ 写的内核，据说这个内核的代码量比 Windows XP 还大，连他们自己的程序员都维护不了，最后当然就死掉了。

简而言之，面向对象的代码风格：一个字『繁』、两个字『繁繁』、三个字『繁繁繁』

把 Python 视为非“面向对象”编程语言并非大逆不道，事实上，也有许多人认为 Python 是一种类似 LISP 的“函数”编程语言

笔者从事编程十余年

（敲黑板！）

，从未用过面向对象的编程模式写一行“class”（类对象）代码，依然可以应对各种编程工作

“面向对象”的鼻祖 C++11 标准，到 2015 年依然处于推广阶段，而且争议纷纷。

“面向对象”过于复杂，与“人生苦短，我用 Python”的优雅风格天生不合

可是我也这么想：虽然有时候我们希望 Quick hack，做我们想做的事情，写点小东西自娱自乐（有时候不一定非常辣鸡，也可能只是比较精巧而已）或者写点『复杂的堆砌』（就是规模大一点的小程序）出来，
但是，实际上世界是极其丰富多彩（̶e̶g̶.̶ ̶与̶你̶无̶瓜̶、̶蓝̶瘦̶香̶菇̶、̶鸡̶你̶太̶美̶、̶图̶样̶图̶森̶破̶）̶的，有自己 自娱自乐♂ 的需求也自然有 搞♂大新闻 的需求

Intermediate Representation : Literate Agda => 形式验证、依赖类型与动态类型 [博文]

程序员们常常对『动态类型和静态类型哪个更好』这一话题产生激烈的讨论。 这其实是一个完全没有意义的讨论，因为这首先是一个罗卜白菜的问题——两者都有能称得上是『优点』的地方；
其次不同的人对程序有不同的追求，有人想写出健壮可扩展的程序，有人只是想快速交付收钱； 再其次同一个人也有不同的需求，有时只是想批量处理一些文件，有时需要构建长期维护的大型项目。

同样，Continuous EnterpriseDevelopment in Java [GitHub] 这本书的作者也说：

If you are only interested in quick hacks, you will hate Java EE, applications servers andprobably this book alltogether.

Packaging, deployment, monitoring and management sounds like bloat and is bloat, if you are only focusing on development.

However the “DevOps” movement also considers operations and development as asingle unit. Who needs beautiful code which cannot be properly installed in a predefinedenvironment? DevOps is nothing groundbreaking; rather it’s a “back to the roots”movement.

是这样就证明“面向对象编程万恶复杂”是错误的观点？不，但是我觉得，对任何事物都不要盲目武断其性质，对任何领域的任何事情也都应该以这种原则判断

duangsuse 曾经在冰封哥 @ice1000 和 friends 当管理的某 Q群里发了诸如“我觉得 Haskell 的 HM 类型系统很垃圾，无端制造复杂性”[2]这种弱智级的言论（黑历史啊，我都是抖着手打出来的，后面半句是大致的意思）

为什么觉得奇怪、莫名其妙？很大的情况下可能是因为自己根本不理解，正如我开始写一点 Haskell 以后对我上面这种话的评论：

听不到音乐的人觉得跳舞的人都疯了！

参见 Dunning-Kruger 效应，为什么刚入门的小白居然有那个胆量去挑战他们所谓的“权威”？为什么一个普通院校的高中生居然敢以不到一页 A4 纸的篇幅证明几百年（敲黑板）来没人破解的哥巴赫猜想？因为他们真的已经弱到连自己的弱、别人的 dalao 都感受不到了。

所以有时候，看到『存在即合理』这句话，不要忘记它还有一个深层含义：

如果你一看到某件东西就觉得它很莫名其妙，很弱智，那就不要立刻去喷它，因为

存在即合理

。
如果你依然坚持自己的看法，为什么不思考一下，每天有无数人和你持一样的想法，为什么没有人做出点什么证明它真的没有道理？
是因为它后台很硬，还是看不到它合理性的你们 — 都太菜了？

—
[1]: 制造的复杂度大部分就是少量模板的代码，以及对某些逻辑做对象化抽象后过度的拆分，比如 @ApplicationScoped @Singleton @LocalBean @TransationAttribute(...) public class XXX {...} 这种，以及把消息队列的使用给拆成『连接器、会话、生产者』和『消息队列』两部分这种情况
我觉得这句话和“在我们完全无视 Haskell 是一门引用透明且惰性求值语言的情况下，Monadic IO 看起来就像是无端制造复杂度”听起来怎么就那么像🌚
[2]: 我当时真的不止是没有写过一行 Haskell，我是压根一行 Haskell 代码都没有看过。
HM 这个名词是我从王某人的博客上看到的

https://github.com/bytemaster/fc_malloc #lowlevel #backend
才想起来 CAS 是 compare-and-swap 非阻塞并行同步 Atomic 操作的意思

#Learn #hardware #backend #ce

#dev #Android #backend 刚才看到 Pink 酱的一篇文章《如何在Android FC(Force Close)之前抢救下》，正好也照应了我在 pygame 实践里对 message loop 的认知，给总结下：

Android程序默认：

void main(String... args) {
  Looper.prepare();
  initMessageQueue();
  Looper.loop();
  throw new RuntimeException("fatal");
}

可以设置捕获器：

Thread.setDefaultUncaughtExceptionHandler(new _Handler { void uncaughtException(Thread t, Throwable e) {}; });

在里面可以选择重启： ctx.startActivity(new Intent(ctx, _Activity.class).addFlags(Intent.NEW_TASK,Intent.CLEAR_TASK));
也可以用 Cockroach 式：

Thread.defaultUncaughtExceptionHandler = { t, e ->
  logError(e)
  while (true) {
    try { restartActivity() }
    catch (Exception e1) { logError(e1) }
  }
}
fun logError(e: Exception) = Log.e("APP", "uncaught exception: ", e)

我还有一个基于之前观察，关于 Android 线程/执行资源调度的疑惑：
+ 在 onClickListener 里，不能做一些View树的变更，说明 handler 应该在 Main 线程外执行
+ 可是有时候 onClick 里的 HTTP.get 逻辑能阻塞住主线程导致 ANR
如果是主线程负责所有绘制，嗯这个的确没问题

出现问题的环境不一样，二者分别是在 Beanshell 解释器、Androlua 里执行（我也没有用纯Java做阻塞操作的经历，但有一次的确是在 onClick handler 里阻塞了重绘）
所以 onClick 到底由谁来 run 啊

struct,json,yaml,pickle,marshal 等序列化便利库我都用过，无非就是流 dump/load 和便利性 dumps/loads #Python #backend #bin

对于二进制读写的数值读写、字节序解释我也清楚的很， Kotlin Dokuss 和 SomeAxml(挂名) 项目都包含了基本二进制流和读写抽象

序列化(serialize)的用途一般是以二进制表示某种数据， marshal 和 pickle 虽然都是对象序列化，显然 marshal(封送) 更广义、更内部， C# 里也有这个名词，用于在进程间传递数据对象的深拷贝，也类似 android.os.Parcel 。

#windows #sysadmin #backend

#CPP #backend

#os #android #backend #huawei 总的来说，可执行格式和渲染上还是有转移和割席的，但是还太少，所以说像酵话

#linux #sysadmin
YuutaW:
(用fbi无chroot在 #Android 上显示了图片)
以及，fbi 也支持 DRM

duangsuse:
我也猜到 fb=framebuffer ，就是不知道有 imageviewer 这程序……

drm 又是什么缩写

YuutaW:
Direct Rendering Manager
/dev/dri
/sys/class/drm

请妥善使用 drm-info 工具

duangsuse:
噢，我也知道，和 Digital Restriction Management 误会了。

YuutaW:
确实容易误会
和那个东西没一点关系
就是一个 Kernel 的新的（Relatively）显示栈

duangsuse:
所以经常不容易区别 nvidia-drm 到底是干什么的（

YuutaW:
我是 chroot 的啊

duangsuse:
🌚我还以为你是 Termux 之类的，所以专门强调无需chroot

YuutaW:
chroot 只是使用了 Arch 的一些 Userspace和库，dev 还是 bind 过去的。
理论上静态链接一个应该也不用 chroot ，但是太难了，简单起见。

DRM的参考文献： #cg #cplusplus #backend

https://events.static.linuxfound.org/sites/events/files/slides/brezillon-drm-kms.pdf
https://jan.newmarch.name/Wayland/DRM/
https://waynewolf.github.io/2012/09/05/libdrm-samples/
https://www.linuxplumbersconf.org/event/2/contributions/229/attachments/53/60/10._DRM_KMS_for_Android_v1.pdf （注：YuutaW 的发言有整理）

👆辟谣！现在没有对$i30屏蔽处理！
#linux #sysadmin #os #backend https://t.me/c/1229493248/21869 (@outvivid)