因为真正绕的地方都会写给自己看的注释，比代码还多得多，于是——

我 x ，我以前这么厉害。
+
我 x ，我以前这么厉害，还有这么奇葩的跟文档不一致的写出 bug 的姿势……
+
我 x ，我果然更厉害了，又看出几个能优化的地方……

（反正大多代码都集中存档，很容易 diff……）

说到 VC++，倒是想起了个亲身经历的笑话（？）——某个 CAD 软件的扩展 API 只提供静态库并且只支持 VS2008SP1 的 libcmt ，搞得扩展项目连 msvcrt 都链接不上去。为了复用另外更多的其它组件（ C++标准库），不得不同时安装 VS2010 ，另外糊了一坨 nmake 才自动化。
如果一开始给源码而不是静态库的话就不会是这个光景了。（甚至只给 dll 都比给静态库强。）
VC++的 V 的部分：简单来说就是被 VC#去掉 C#以后的部分吊打的份，不用自取其辱了，余略。
Delphi 么，想黑 ObjectPascal ，又不值这铜币，也略。

@g00001 “别忘记一个最简单的事实”之前你得记得更简单的常识：指名道姓地惦记具体系统的支持总是比无视差异更累。
凭什么开发者就得记住这种所谓的事实才能开发出桌面应用？注意，就说开发出能用，不说优化适配。
除了系统厂商本身始作俑者，还不就是因为看到跪舔具体几个“占有高”的实例偷换桌面系统的概念的开发工具作者多了，搞的平台差异千疮百孔不但没尽本分掩盖住反而更随便就暴露了，才逼得下游开发者鸟这个问题，进一步让最终用户吔翔的么。
系统不是你造的也就算了锅不都该你背，但什么时候劣化这种局面还光荣了？扯远点说，用户对 Linux QQ 矮痤丑的怨气，你这样跳出来不务正业强辩的，也是得老实接住的（而不是数落 Linux 社区无能，毕竟丫一开始就没打算对 userland 负责）。

@g00001 哦，我上面那个“代码少”主要只是目标程序的。虽然你没明确说源程序，我还是先澄清一下我从来就没觉得少。
你拿库举例虽说是显示跨平台意义可疑，但刚好这方面有点搞笑，所以我借用一下：基本上随便一个通用点的语言都能这样写，就是看包装库的工作量。
（ Aardio 的库基本全是第一方提供的，以至于库是不是容易让一般用户写得出来就成了疑问。这反倒是在给语言的抽象能力打反广告。）

不但不少，我还嫌弃一些重复废话多。
比如你先前贴的有几行 dataTable.Columns.Add 重复的源代码。这个要是窗体设计器生成的还好说，让人手写就别说少了，实在没下限。
你要能改写出这种：
map dataTable.Columns.Add ("名称", ("计数", System.Type.GetType("System.Double")), ("选择",System.Type.GetType("System.Boolean")))
然后确定 map 这种高阶函数之类的不是语言内置特别开洞的规则或者“关键字”，而是开发者自己也能轻易实现的，那才算真的有资格说能“代码少”，否则适应性太低了。（但是这样其实基本规则不会简单到哪去。）
也就是类似的原因我很早就对 RAD 界失去兴趣了。
这倒也不是针对 Aardio 这样的具体方案。地图炮撂这儿：大多数画窗体和表单走量的，自己整不出框架的，都对估计源代码复杂性一样少跟筋，口味也属实有问题。

话说回来，硬要把 TrustedInstaller 这种无中生有的接口移植到不支持的环境也行，报错得了嘛……当然看上去有点蠢，做无用功。
但比起支持可移植性，对大多数一般开发者来讲，首先支持 TrustedInstaller 这种旮旯才显得更离谱。
这种非通用机制本就不常用，再好用也掩盖不了你一个开发工具在最重要的“提供通用抽象”的问题上的无能——基本功就是干掉不是用户自己主动引入的平台依赖。

其实只要别往这种一般需求上凑热闹，你只要承认 Aardio 脱离 Windows 一大半活就开发者自己都实现不出来也没啥子嘛。没那么通用罢了。
我觉得你好像就不会用“胶水语言”这个调调来包装——其实这才算是 Aardio 看上去比较正常的定位。但这样就是在抢 Python 饭碗了；是不是觉得大不敬，不敢造次了？

@g00001 我不清楚 xxx KB 的 yyy 解决了什么问题和这里的问题有什么关系；我也没这种问题。我就知道 OP 想跨平台，你的方案都不合适。
但是既然你一直想发散，那我只能指点出你的常识性错觉。

>“开发速度快”
熟练的和不熟练的可以差很多。
还是那句话，搜索资料的成本都有潜在风险。据我搜到的东西来看，我没法相信新手算上学习熟悉的时间后能快哪去。

>“代码少”
怎么说呢……虽然一般算是优点，但非得强调小到几百 K 的话，除了网络攻击渗透作弊之类的非常规的“专业细分”市场，小到这个程度是普遍很不被的用户在意的，如果不是反而可疑的话。
大部分的桌面用户，不是要求折腾 Qt 的 debug 库之类的玩意儿，一般桌面大个几百倍也不是不能接受。
所以你能确保把几 G 砍到几十 M 这个算是活菩萨，但接着砍到几百 K 这就算是大部分用户基本无感知而不那么值得解决的问题。

>“无外部依赖”
真依赖系统调用接口写应用虽然不是不可能，但很脱离实际。而且一但依赖的真出问题，要做安全更新之类的就蛋疼了。
所以实际上，跟智子锁死百度 GCC3.3 的笑话一样，基本只能实现强迫用户使用系统自带的低版本用户空间古董依赖罢了。
另一方面，这也是在纵容旧版本系统和过气的软件实现栈。
Web 就不说了，主流桌面开发者也很烦这个。这不仅在现在的 Windows 阵营很不受待见，别的生态也一样，特别是没第一方维护的版本，连带系统（比如 CentOS ）和专业倒腾这种环境的开发者一起鄙视。
所以不说还好，一股吹起来，这个越看越是缺点。

其实无外部依赖这点我和不少最终用户也不那么在意。一点相关的题外话：我倒是会例行鄙视刻意鼓吹“无运行时依赖”的语言设计：说得好像操作系统提供的运行时和 CPU 提供的硬件运行时就都不是运行时依赖的一样。
硬件提供的撑死了只是方便部署，也就是在包管理之类的系统部署方案残疾的环境中才会有原则性区别。部署有问题不想着怎么取解决反而砍功能需求，这也是活久见。
（点名批评静态链接党，包括传统意义上的 cat-v 逗比以及 go 和 rust 之流的。Aardio 如果只是擅长在这里做文章的话，就很荣幸跟这些货色并列被婊了。）
同样的道理，这些语言也就是吹“写小工具”的时候，这类不灵活的缺陷才能接近于零。软件规模往上堆，被坑是迟早的了。

> VC++ 不开源，所以没解决问题的资格？！
倒不是说资格的问题，而是除了为了错误的选型等历史包袱买单，没理由去用。
VC++的 C++实现长期被开源实现吊打，直到最近微软的 C++标准库实现开源以后才在进度上扳回一城。

> Delphi 不开源，所以没解决问题的资格？！
> VB 不开源，所以没解决问题的资格？！
这俩字面意义上地过气了。如果开源的话，可能还能抢救一下。
虽然也就是抢救一下。

@neutrinos 你是在回复哪一楼？
macOS 社区和这里讨论的有多少可比性？ macOS 自己就是有足够官方商业支持的产品，而应用适配大多都是应用厂商自己主动推进的（对比 Linux 和 mac 的 QQ……），国内有谁依赖 macOS 社区提供什么服务，这些服务有包含具体什么原厂没有、用户明确需要的支持？……认证？黑苹果？

@neutrinos 社区是不是需要我代表这个问题搁置，我是不是有资格也不提，首先我没有兴趣代表“国内”。所以你的动议无效。

你要是对我的事实判断有异议，麻烦直接提出反例，看看是谁了解的情况有问题。

@james122333 安全性这个话题的口水来源之一就是需求没有上界。你可能认为某个应用够安全了，但换个环境别的用户就未必。这没法定义清楚。
所以跟你说的类似，现在系统设计者基本也不会替用户决定应该安全到什么程度，大多只是提供材料（安全机制），让用户决定怎么用。但系统的用户包括应用（开发者）和最终用户（系统管理员），究竟何者来决定，就比较微妙了。
这个问题还涉及公共安全决策，比如浏览器厂商决定不提供 http （强制 https ），各方利益有冲突而更加混乱。考虑到 http 确有合理用途（可控的上下文中避免安全实现的开销），这更应当让用户自决而非供应商独断，即便用户决策错误，也不会自然坑到决策正确的其他用户。UNIX 权限的问题则略有不同：它是半吊子，明确想要安全或者明确不想被安全性成本拖累的两边都不讨好，维持现状也无助于改善混乱局面，除了用脚投票的用户也就是系统厂商的责任了，应用厂商反而没什么存在感。
无论如何，至少有一点还是确定的：最终用户多了解现状，多明确表达自身的需求，多参与安全事务的决策，对整体减少非预期安全风险和安全实现的开销以及解决历史遗留问题都有好处。

看到 @skinny 的说法，我重新审视了一下这楼的问题，觉得有必要澄清。
上面所有楼层的回复，除了最开始两个以及我说的，没体验直接信都有直球误导的风险。
因为这些观点不说是否正确，至少都是片面的。

比如说：
@villivateur 从来没有靠几行代码把系统搞崩的体验照样可以掌握好 C 。
@chuanqirenwu 从来不学 C++也可以学好 C 。（虽然我不反对学 C++作为长期性建议。）
@ZXYF 学好 C 不保证能理解清楚大部分 Python 复杂一点的东西，反而可能养成依赖实现细节的坏习惯而学坏。
@jones2000 这是个进阶学法； CPython 的 C 这样的互操作不是适合新手学习的，虽然程度整体比混用 C 和汇编来得容易（因为 CPython 对互操作的支持相对非标准 C 的“官方性”更强而更完善）。
@ch2 不学 unistd 而使用 C 的价值仍然存在，比如制造和 unistd 并行的东西。Windows NT/ReactOS 执行体也是基本都用 C 写的，这也算操作系统，但和 unistd 无关，所以你说的还有点自相矛盾。注意嵌入式还有没操作系统的独立实现。当然，市场上讲非操作系统的东西用 C 来讲没多少收益。

而学会怎么写程序，说实话和是不是用 C 没什么关系。换别的看上去通用点的语言一样是这个建议，但一样不会让你特别地学会某种具体语言。
其它白开水观点不评价。
我强调的问题是，C 特别容易让人陷入表面上学会而实际上了解的另一套玩意儿的问题。极端点的就是谭浩强 C 。“C 没有对象”是另外一个常见的误解。这种错误通常不能通过你会不会写程序做对几个题目检验出来，直到参考文献推理一些具体的问题到底是谁做错的时候，才发现很容易被坑。

避免这种问题的简单方式就是阅读相关的文档。任意不足以区分具体语言和其它语言的区分的文献都不算是足够相关的。
务必摈除某些人认为的“装逼”思想。阅读文档理解意思这就是专业用户吃饭的本事。并且，这就是工程师这个职业的本职工作和区分于其它分工发挥价值的地方。
所谓“用”，反而是形而下的辅助手段。极端情况下一个用户可以化身人肉编译器在没有编译过一行程序的情况下“学会”某种语言（特别是在这种语言不存在实现时——这才是真正能算装逼沾点边的，但也就是专业人士的家常便饭）。
然而没有谁能虚空脑补出别人决定的设计。

自测具体语言的了解程度的简便方式同样直接阅读相关上下文的任意的文档，至少能有自信了解大多数是在讲什么，比如：
www.open-std.org/jtc1/sc22/wg14/www/docs/n2396.htm
毕竟，如果连 bug report 都看不大懂，这也水过头了。

@g00001

> aardio 支持十几种编程语言，不等于要会十几种编程语言。
至少还是要会其中任何一种语言吧，否则就只能用 aardio 了。
那么找开发资料会有潜在困难，这个问题上面说了。
只会 aardio 的专业人士我也还没看见，所以交流也是个问题。

> 这是“添乱了”？！
只是提供选项，增加选型成本（起码需要花时间了解 aardio 能干什么）而无助于解决 OP 这样的问题，结果上看就是添乱了。
如果只是要针对非专业人士提供工具，那就找准定位，划清界限，而不是全都要。

> aardio 写的录屏工具，780 KB ，没解决原来的问题吗？！
> aardio 写的桌入法工具，960 KB , 解决原来的问题吗？！
我太不清楚你所谓的“原来的问题”是什么。
我的问题就是嫌弃半吊子方案太多了，没有在业界形成共识，导致各种不痛快。
基于很明显的理由，既然 aardio 连能定制核心的源码都没给，那就没半点解决问题的资格。
我的问题不算数的话，要么你问 OP 去。

@neutrinos 除了厂商以外没谁提供这类服务，而这算是刚需。

国内社区力量不强，更加没法指望非商业机构替代。所以还剩下啥？

学 C 对大多数没像样基础（指只摸过 Python 这种缺少严格的 spec 语言入门的）用户来说，最大的收获可能是知道 C 真有对象。
不开玩笑。

@neutrinos 然后认证之类的转包培训机构，适配指望腾讯们发善心是么……

@dingwen07 这利润算高还是算低？销量估计多少？成本如何核算？会计准则？

“不用说了”感觉很多人可以直接就地失业了。

@g00001 作为桌面开发者，我对 OP 面临的半吊子开发方案到处都是的碎片化现状极其不满意。
不说 BS 应用，不说移动端，桌面 GUI 的整体需求应该足够明确了，市场够大，投入不小，为什么几十年来会整成这样？
“人类命运共同体”就是在黑整个业界各玩各的，谁也不服气谁，结果不说产品级方案够不够跨平台，就没整个像样的选型指导结论共识出来，搞得下游的开发者被迫站队跟着各玩各的。

原则上，你要提供一种新的方案当作选择没什么问题，但是没解决原有的问题还会有效添乱的话，那我自然不会有什么好话。
你所谓的好评，我自忖了一下，大概占据这个市场的比例不会多。当年我会按键精灵的小屁孩水平可不怎么有把握学会这一大坨，但是真会专业开发技能时，又发现这些东西完全不够看了。
而有希望成为 Aardio 目标用户的，如同上面我找到的第一个 low 的链接所说一样，可能真只有所谓的“熟手”（先不管别的方面说的是不是真的 low ），也就是退役的职业桌面开发者或者怀旧党。
具体问题很多，比如你支持 Aardio+Python ，表面降低门槛，但实际上新手连 Python 都不熟练，要同时掌握两套体系有那么容易？

另一方面就是严格的 GUI 开发本来就有隐含的门槛。
比如 GUI metaphor 和所谓控件的联系，比如事件循环，这种东西怎么明确通过 API 中的实体表现出来？讲不清楚这种道理，只是鼓吹什么样的显示效果和表面上怎么短的代码对应，是不可能简单到哪去的。（我黑 imgui 不算 GUI 库道理也类似。）
遗憾的是，我找了一圈没找到系统化描述这方面整体设计的相关内容（也可能是我没找到）。
即便是专业开发者，也得猜哪里要有等价的功能；要是能随便容忍这种缺陷，这就不只是专业 GUI 开发者，而是框架 hacker 了，自己有资源就一定能手糊出整个解决方案的那种。这种用户的忍耐是用在 Qt 这样的业界主流而不是 Aardio 这种小众方案上的。

再上纲上线一点，随便挑一个出来讲水都深得很。
比如事件循环，说白了是所有交互式程序（包括 REPL 和像样的 GUI 应用）的公共框架，作为 trampoline 是一类解释器的实现的 top-level ，也是 CESK 这样对应现代的形式语义的抽象机乃至当前物理 CPU 的顶层逻辑结构。所有这几样东西我都像模像样地自己独立实现或参与制造过，不是在工作中就是现役仍在日用的私货上，所以有第一手经验证明这不是理论废话。
基本上这些东西都有一些现实上的缺陷而让我不能满意。所以我对现状的不满其实已经收敛了许多，你觉得我有兴趣纠结区区一个局部的坑上，特意针对具体方案来形而上地黑嘛？

最后，你应该能看懂，我之前说了那么多，完全是站在鄙视区区一个桌面 GUI 都还要纠结跨平台的整个业界的专业用户立场上的。所以你觉得我是 Aardio 面向的用户群体嘛？

@timpaik 直接切中要害所以我本来不想复读，不过这里关于 Aardio 还有个公共问题。

就跟我上面评论为什么 wx 不好（或者说不指望有什么好的未来）一样，一个主要问题是本身的结构导致可扩展困难，在二次开发集中体现的。
这导致的长期后果是继续保持市场上桌面 GUI 开发方案的碎片化，不够解决 OP 纠结的问题，还可能加剧恶化这种状况。

我找了下，Aardio 似乎就根本不提供核心实现的源代码。这就是更极端的问题了：根本不可能实现对核心进行二次开发。
如果开源，即便不提供官方支持，或许还有哪个第三方可能有兴趣移植（尽管可能跟.NET 一样过于依赖 Windows 而长期不成气候），还有资格在这个问题里作为候选；但没源码直接就是画地为牢，自绝于（专业）用户了。
即便库给源代码，但是 Aardio 又不是标准化的语言，市场占有没优势，也没什么超过 Python 之类其它流行语言独立开发的特色，有多少专业用户有兴趣贡献源代码？
所谓部分跨平台，你要 C/S 分开说还好，但看样子全是客户端的，有多少实际案例？ B/S 方面，相比 cef+前端全家桶，有什么优势？
面向非专业用户的低代码工具么，看例子实际代码量也不少。只是省掉中间代码，能吸引多少用户姑且蒙在鼓里。
所以除满足需求的能力存疑外，这个定位各种方向上都很迷。

@duke807 你的确没直接说图形界面不重要，但是如果稍微多使用一点，就会发现即便只是日常使用，gitk 都相当不够用（再怎么说 gitk 也只是集中 log ，而 log 外各种各样的重要功能太多了。）所以如果真关心的话，一般很容易发现不足而比较过流行的同类产品，这样就更不应该发表那么轻率的观点（哪怕你只是把各个软件的主界面截图搜一下都能看出不少差别）。
不过你显然连 TortoiseHg 的官网都没找到或者仔细看，否则不会那么容易误认为“第三方”。所以我有理由怀疑你认为 GUI 至少在这里不太重要。

同时我也没妖魔化命令行。我只是说 git 的命令行尤其不好用（乃至于有用户自己包装命令行），GUI 只是新手的救星。同样是命令行，hg 就正常得多（虽然也有些问题）。
而且即便是 TortoiseHg 也不是完全覆盖了日用场景的命令，也需要命令行补充（其实 TortoiseHg 自带控制台能输入命令，但是我的系统上有其它包源安装的 hg ，我经常开终端混着用），特别是还有非官方插件。（我日常 push 就是基本在终端连续操作，因为 hg push OSDN+(hg-git) hg push GitHub 之后顺手还要 git push 到其它 git mirror ，还是全终端顺手。）

（我在其它地方有时候的确会“妖魔化”命令行，但一般是黑 shell 不够靠近“正常”的编程语言，是以 API 而非 UI 的角度来说的。作为 CLI ，黑命令行基本都是黑 cmd ，偶尔黑一下 ps1 。）

@g00001 我没听说过（或者听说过忘了），随便百度了一下。
一般开发者倒不怎么首先会关心难不难学的问题，而是开发资料是不是容易找。
于是这社区建设看起来比较捉急。
或者至少 SEO 没做好，以至于直接搜就是那么 low 的评论。
而且看上去不是一个两个的问题，怕是快人人喊打了，也是蔚为奇观……
zhihu.com/question/39393984
像这个是不是更 low 。不过你都直接上镜了啊……
v2ex.com/t/249946#r_2808385
倒是理解为什么 SEO 上弃疗了。

@g00001 你这方案看上去可能一些方面维护成本很可能会相当地高：www.cnblogs.com/yaoyue68/p/14327559.html

@g00001 不差钱也可能不行，有的项目进度卡的可能某些方案就是神仙也没法及时开发出来，选型上只能各种抠了……