历史的行程
回溯历史，一些编程语言在诞生之处可能并没有多大理想和宏伟规划，C语言的发明者丹尼斯·里奇就表示发明C语音只是觉得它有趣，最初C语言只用于代替汇编语言为小型机DECPDP-11编写UNIX操作系统。
从语言演化的系统发生树来看，1960年后几乎所有“新”语言只是那些经典语言的子孙——光从模型而不是具体特性设计看就是这样：大多数语言的操作语义几乎就可以是λ演算的直接扩展，而Unilang使用的vau演算是对某种元语言进行扩展。不论前者如何完善，理论和实践终究会要求填补无法完善的空缺。
经典的语言也是不断完善的。从CPL——BCPL——B——C——C++这样的发展路线来看，有些语言在早期没能成长为参天大树，但基于该语言的后继者中不乏在内容上一脉相承，并开花结果的例子，而这样的发展并不只是少数作者乃至一代人的成果。Lisp是另一个典范。正是因为数代设计者的不断设计改进，使其看上去似乎从来都没完全落地，却不断对整个语言的发展史做出贡献，如递归调用和lambda这样的特性还被历史上不相关的其它语言分支采纳了，乃至成为了当前高级语言的标配。
Unilang设计的方法论决定它有代替Lisp作为根节点的潜力——有些东西是Lisp靠参考自己的后代或同时代的大多数其它语言都不太可能演化出来的（比如类似Kernel背后的vau演算的语义模型，比如如何允许不依赖GC和全程序分析的PTC）。
从这个意义上，Unilang作为一个语言项目，只是顺应历史的行程，应运而生而已。诚然，现在的Unilang与那些已经功成名就的编程语言无法相提并论，但具备了无限可能和后续不断改进提升的机会。不论之后是否能完美达到预期的应用领域的成果，它已经占据了历史的一个节点了。
为学习减负
Unilang在许多具体设计上并没有随大流。许多开发者也十分关心为什么Unilang的风格如此独特，看上去难以学习理解。
这里也许有一些误会。Unilang的设计并非追求迎合与满足所有用户的口味——实际上因为通用的领域中不同用户的口味冲突，那也是不可能完美实现的。相对地，Unilang选择在设计上支持大多数开发者背后面临的一类共通的实际问题：语言的伸缩性不足，不够适应对应的问题领域，使开发者被迫学习更多的不同风格的语言——这可能本无必要。
对开发者而言，完善的语言在理想情况下能使所有感兴趣的开发人员得到相对当前情况的效率提升，只要开发者能正确理解他的最需要解决的特定领域问题。只要不是诸如“改进语言设计”这样的领域，那么就不必十分关心语言发展的具体细节。
背离这种理想情况，便是当前情况的一大问题：即便开发者理解了业务，也可能和不适应问题领域的不够优化的通用目的语言“作斗争”，浪费时间精力在适应不合理的语言特性、解决技术冲突和版本兼容性问题，甚至和语言设计人员扯皮直至放弃，而投入资源开发或学习领域特定语言（DSL）上（然而学习这些经验经常难以复用，甚至形同鸡肋）。deepin显然希望Unilang的通用、可移植和可扩展的体系能从源头上尽可能消灭这些问题，即便是需要DSL也不需从头设计，而能轻易复用生态中的既有成果。
现阶段，Unilang基础语言首先从无到有地提供“专业扩展语言（的语言）^n（n≥1）的设计”这个小众到从没被工业界足够普遍重视的专业领域的解决方案，验证方法论的可行性和有效性。Unilang上层语言则提供“桌面应用开发”为代表的、当前专业开发者中的主力关心的领域的一个至少在部分关键属性更强（如灵活性）或不弱于（如可移植性）当前一线解决方案的替代，进一步验证及展现这一路线的可能性以及未来。
因为当前大多数开发者缺乏对底层关键技术的场景的接触，更不大可能接受丰富的专业训练，使用基础语言需要学习不少不常见的知识和技巧，这在表面会是直接的负担。但并不是所有的开发者都需要精通这个领域而熟练使用基础语言。掌握基础语言自然仍是有利的——这种经验至少相对独立的碎片化DSL更能被复用。不论是否对底层领域感兴趣的开发者，最终都能找到适合他们用Unilang派生语言解决的问题，而不必投入太多的精力学得面面俱到。Unilang的整体生态越健全，这种优势越显著。
当前Unilang的语义模型是lambda演算的保守扩展，能推理的却不止是Unilang现有的语言特性。主流工业语言的特性原则上都能用理解Unilang的方式表达（计算上可表达即图灵完备，但这里是抽象上保持语言特性“拓扑”不变的更强的高阶属性——技术细节略）。Unilang基础语言的会略难于单独的工业语言，即便它少了具体类型系统的大量规则——因为它在很底层的站位上提供了能包涵大量常见和不常见语言的特性并集的少数原语。这种抽象和精炼对大多数通过工业语言的用户是陌生的，而一朝掌握，世上各种（高级的，即所有有“变量”和“函数”的）编程语言的核心设计和公共实现就“尽在不言中”了，反而能快速上手其它语言的语义的快速学习，更节约整体消耗。
不过，考虑到当前计算机专业本科教学连更基本的lambda演算都无法覆盖（或许今后20年内可改善），一般用户掌握这里的模型的可能性不容乐观。退一步，理解上层语言可能有短期收益——不过这更依赖deepin的框架方案的完善度和可用性了。
希望和现实
放眼未来，最理想的情况下，Unilang可成为业界标准的、开放的根技术，在一定程度替代C++和JavaScript作为最主要的通用目的（同时不仅仅是面向专业开发者的）开发语言的公共基线，比现在的主流语言更适应全场景的开发需求（不限当前强调的桌面应用，也包括服务器应用乃至系统）。
在覆盖的问题领域的广度上，发展完善的Unilang及其派生语言可能将会是实用工程语言发展史中，到当时的最激进的一次全面尝试，在理论上也将是靠前的。
当然，当前阶段产品的目标只是其中的一小步：提供一个初始设计和试验实现，在一定的桌应用开发场景下能作为首选技术之一，同时仍比现有其它语言更能平滑过渡到实现理想长期目标的技术路线上。
对UOS而言，作为deepin的下游发行版，会获得相应的高优先级支持，而有机会率先在同类产品中更早和更成熟地应用有关技术，在市场中获得先机。在生态建设上，作为理论和实践中最接近根技术原始字面含义（被依赖的节点）的原生技术（考虑开发语言是极少数能从上游全主命周期地影响操作系统内核演化的核心技术），这能对UOS整个生态起到非常深远的、全面的（不论是否局限于技术方面）、长期影响。若推广这类上游技术的时机和方法正确，这对厂商意味着相关市场的全球话语权。当然，当前项目仅是起步，未来尚不明确，不过，万丈高楼平地起，未来还是可以期待的。
