“文本”格式，首先自然是纯文本(MIME: text/plain ) ，虽说本来就是“无格式”文本。
任何纯文本编辑器都能当简易的笔记软件用——调教到极速冷启动时间无人可挡。
纯文本在更底层还是要区分两类实现意义的格式的。
一个是文本编码。用于外部交换的持久格式，基本都 UTF-8 省事。
二是封装格式。首先要日用编辑，不会使用压缩，所以负载就是 UTF-8 流。（要压缩都另外打包了。）
所以剩下的要说格式就是按行分隔的封装格式：我用 UTF-8 BOM + CRLF 。
BOM 是因为可移植性实质上有保障（没 BOM 换个随便什么的编辑器出来的乱码妈都不认识，特别是 Windows 上）。反正我没打算拿笔记来 cat （能 cat 的东西本质上其实是 appliction/octet-stream 了）。
CRLF 是因为很多足够多的公开规范在使用（例如 HTTP ），以及没 POSIX 党的 LF 那么 trivial （要二进制模式就二进制模式，不要二鬼子的伪装“文本模式”的二进制模式。）

其它的，要拿来写文档的还是首选 Markdown，支持的工具到处都是而且 UI 输出有保障，而且实在比手写 HTML 省事多了。
Markdown 比较蛋疼的主要是方言乱七八糟，不过不考虑个别特别残废的（比如 Bitbucket wiki 没 inline HTML 甚至没 anchor ），公共实现还是挺多能用的，再不行 embed HTML 。
没发现别的竞品有特别突出的优势，不是测评就懒得多碰了。
要排版的……这个不算笔记了吧。

有些 txt 我是自己写语言发明格式转换成结构化数据来用的。通用化以后，大概就 PicoLisp database 那种类似物。

题外话……OneNote 嘛，好用不好用甭管，看它没法对付我一坨陈年 .pwi 的面子上，还是扔了（

@Arnie97 Point-free 说的是一种 style 而不是 transformation，第 3 条那个也没做到 point-free （消掉了 $testPath 这个 point，但 $_ 还是 point ）。
另外，point-free 跟可读性沾不上多少边，“尽量 point-free ”在抽象能力上倒明确是一种倒退。（虽然这个上下文中不明显。）
https://github.com/FrankHB/pl-docs/blob/master/zh-CN/combinator-critique.md

@AndyAO PowerShell 作为一个传统意义上的 CLI shell，本身是做不到真正即时地渲染补全结果的，它需要借助 GUI shell （具体来说典型情况下就是终端模拟器）的功能。
而这点上，至少默认终端 /控制台的交互性不算很好。而论直观性，这方面终端模拟器也难以做出典型的 IDE 那么好的 UE 。
其实 MS 应该明确知道这点，所以才有 PowerShell ISE 。问题是多少 shell 用户会真习惯这样来代替 cmd 的……也就是多个不太常用了选择了。
补全列表在不太重量级的终端下这只能做成一种后验的反馈而没法总是及时即时更新，如果用户不选择是无视而使其有意义，就需要关心到底怎么获取列表信息，具体来说就是看到并且 parse 屏幕信息。（说实话 IDE 基本上也没好哪去，但是能用 IDE 的场合往往没那么“急”，即时性要求反而一般不高，而且好歹允许做得更动态……）
非即时反馈对轻度用户来说还可以是帮助（只要性能别出大娄子明显影响到响应性），但重度负载下就会容易出来我提过的阻碍人脑“乱序执行”的问题。这里所谓的重度用户，是日常需要高频进行某一类近似但又没法确保自动化的操作的用户。（可能有人觉得这主要是运维 /DevOps，但用惯 CLI 的传统开发者这里 APM 也可以很高。）

像学习历史记录提建议这只能说是一个帮助轻度用户习惯和适应的过程，对重度用户就不太有帮助了。特别地，不保证 100% 准确而必须让人去盯一下反馈再确认，这比起闭上眼都能键盘一把梭，差距是消不掉的。
这些问题其实是所有 CLI shell 共通的问题。PowerShell 在这里并没法有效突破限制，又没几个人会把 PowerShell 当成年轻人的第一门语言，没比竞品强太多的情况下，特地去上手就有点鸡肋。

我所知的 PowerShell 最擅长的还是它能调 .NET 运行时的功能比较方便，有效缓解 .NET 语言传统上缺乏成气候的 REPL 干杂活不方便的问题。（题外话，CLR 上的一些动态语言一直不温不火，C# 和 Java 的 REPL 出来也有好几年了，甚至 C++ 的都有很长历史……这些环境没普及可能更多是用户习惯而不是语言自身限制的原因。）
就算抛开历史习惯不提，真日用起来 PowerShell 比起 sh 是没有决定性优势的（终端模拟器都是适配 sh 的更多点）。
而只是写脚本，实际项目都不见得打得过稍微认真写的 shell 脚本——举例：安装 Flutter 的那坨 ps1 就比 sh 多写 bug 报错更加云里雾里……

说到这里确实是有点跑题，不过我倒是不觉得闲了就原主题做点头脑体操完全没意义——只不过大多数人应该没到这个程度罢。

要开发教育客户什么是傻逼？
这是穷到了老板和开发不是同一个人但开发还要兼任售后客服？

@fannas 考公能容易薅上能远程的职位不……

也有少数情况写起来短是个优势，但并不是主要被接受的优势——短的写法可能更有可读性。典型例子是正则表达式中的最常用的语法：一看一个 * 就知道是重复 0 次或多次，换什么更长的写法来“可读”就都没个准了（大多数用户都未必知道这来自 Kleene 星号）。这个事实基于正则文法本身的简易以及这种约定的符号使用的广泛性上，以至于短的写法就是标准通用词汇，要强行展开成自动机程序搞得大脑暂存区溢出才是鬼画符。当然正则表达式（的不同方言）里面比较少用的旮旯就没那么有群众基础了（还有个问题就是符号不大够用），所以才会不得不有 [[:alpha:]] 之类明显画风不一样的叛徒……

@nightwitch 那个说的是系统调用，用得没那么频繁，不用太在乎日常输入效率，反倒是不刻意习惯就容易读到一次恶心一次，强行习惯还会“没用的知识增加了”，自然要纠结 crate 还是 create 的问题。
要说终端交互式使用，就算现在的键盘按起来没那么费劲，成本也不是零，而人干这活往往不会老实严格串行傻等反馈，所以输入一长就麻烦。补全也不是解决方案，因为前缀不长到一定程度，很难预测补出来的东西会是符合预期的，结果负载一大就该纠结“我这个命令到底输入到哪再补全比较好，万一不对该怎么操作”了，严重影响操作者的乱序执行效率，或者总是会增加人脑的调度负担。
要是设计得像样就该被接受，scsh 不早该就把 POSIX shell 打得满地找牙了，而不是有自知之明“只适合写脚本”。
所以到底是要简短还是要看使用场景是否要求交互式输入（一次性代码）。你要拿个终端输入命令，那就是输入顺手的短一点比较好，看着像鬼画符也忍了；你要考虑写重复使用的脚本或者被复用的脚本模块，那就更适合用看起来罗嗦点的更正经的编程语言。
（推论：Perl 那种读起来呵呵写起来也快不到哪去的就老实凉凉吧。）
这里的界限不是严格的，但使用场景本身就不太可能混起来，所以其实各种 POSIX shell 替代品都挺尴尬的——脚本可维护性上用脚打都能干死 shell，然而实在没法在保持适合写脚本“优雅”的情况下日用起来更简洁。

@charlie21 道德显然不只是律己的，否则就没公德这回事了。对他人的道德约束来自于认同道德规范的共识，和法律相比主要就是实现强制力的不同。
此外，不论是道德还是法律，都只能规范人的行为，而规范不了动机。因为人的认识可以不同，客观上你没法保证随便谁都会同意你以这些规范为依据的判断。（只有物理规律才有在此之上的排面——譬如不论你信不信春哥，该死的就是要死的——爱信不信。）
使用法律显然并不能涵盖所有伦理问题。合法地钻营法律空子，或者制定恶法，都是能符合法律规范但不符合道德共识的例子。
此外，现实就是有很多法律是落后于时代的，能找出很多跟主观理由没有什么关系的不合理之处，例如对维护公平的无能。所以和法律冲突的行为仍然可能是道德上正当的。
至于嘲讽这个行为，实际上没有明显和法律和社会公德冲突的地方（和“请尽量让自己的回复能够对别人有帮助”可能不对付，但这个判断标准又很模糊）。
因为嘲讽本身没有强制力，充其量就是一种“言论的表达”，闻者不悦大可以当作是放屁而不从。要符合公德地否定乃至制裁之，需要有其它的依据；否则，要是能随便塞抹布，会有更明显的违反公德的问题。
只是因为分歧明显到了不可能有什么共识，所以这种行为跟公德无缘，但现在也算不了不道德到哪去的情况。认为这样的行为“不好”大多是基于个人价值判断的结果；并没有谁论证这些行为会造成怎么样的决定性影响。

钦定“好的方向”只有一个，那就是道德绑架了。
同义反复。
什么，不止一个方向？那么问题来了，谁绑谁？

权限要的有点多。
可以考虑插件化。

@ixiaohei 不能打就是因为强迫用 GC，去掉就没那么 shit 了。
虽然习惯 GC 以后多少会用成 shit 。
@yamasa 光一个 stack VM 就是筛子了……
还有妄想硬件实现半途而废的光辉黑历史。
顺带暴论：任何没戏用硬件实现还想臆造 ISA 备胎的 bytecode 方案（光是性能意义上）就是屑。
（其实去掉限定词也没那么暴论； CRuby 改用 GCC 编译源码的 MJIT 比 bytecode VM 快了十万甚至九万倍，可见光是为了性能常规 bytecode VM 就是智商税……）

@nthhdy 你自己都说 free variable 了，这不是变量是什么。
LC 的变量和现代编程语言中的一般意义上的变量(c.f. IEC 2382) 本来就是一回事，无非是默认共享命名空间无视作用域规则。把变量曲解为可变状态是历史上出现得晚得多的脑补，到现在仍然是片面的（按这说法纯 FP 语言里就没变量了）。
@secondwtq 实现所谓的 open recursion 不需要 OOP 。
名称解析直接整个 late binding 就行。不少动态语言的函数体里就是这样做的，函数定义时不管，拖到调用时才确定自然就 open 了，缺的只是没给在对象语言构造捕获环境（能够让你引用 this 这样的东西）的方法罢了。

@BrettD Windows ？随便一个 wsl 把你个默认 FHS 都没兼容的环境打得妈（生产环境）都不认识……
更不说连 MSYS2 都比你原生部署系统省事多了。
而且每个都是滚挂了都无所谓。

讲了多少遍了跟所谓传值相对的是传名……
所谓传引用说白了是传值的一种。
Java 都是传值但没直接把引用当对象的机制，算不上传引用，撑死了算传共享对象(call by sharing) 。能传引用 swap 还用什么 box 。
还有哪来的什么地址，是被什么垃圾来源坑了？ hashcode 一样说明地址，什么逻辑？

@Balthild C++ 反人类的设计显然包括不知所谓的本该避免的文法歧义，使用 <> 多出来的问题就是 C++ 反人类设计的典型杰出代表之一，这不因为其它问题更拉仇恨而改变。你没有一下子搞清楚这点，而强调“并不一定”，看来是不够熟悉 C++ 。（事实是，不想硬抄 instantiation phase 而老实写形式语法的根本没法在实用上绕过这坨○。）
虽然其它许多用 <> 的语言并没有那么夸张的歧义问题，但是用 <> 的必要性仍然相当莫名其妙，有不尊重语用来源之嫌。
选择照抄 C++ 这样设计的语言设计者和语言的用户，大概也不一定了解 C++ 在这方面的历史包袱。而选择不照抄 C++ 却同样使用这种糟粕设计的语言设计者，大概至少一样无可救药（至少没几个语言有当初 C++ 对 basic source character set 那么纠结的需求，也不是事后才扩展出 template 的）。