[Community News] 生而为创新!我们自研的编程语言Unilang问世!
Tofloor
poster avatar
white777
deepin
OM
2022-09-19 17:24
Author

Unilang.jpg

2022年9月,deepin正式公开了自研全新通用目的编程语言——Unilang!


回顾过去,倍觉光阴荏苒:

2020年4月 ,这一年,我们决定开发自己的语言 ,进一步往上做GUI框架;

2020年6月 ,想法成型,经调研分析后,我们创建Unilang仓库 ,提交了第一行代码

2021年3月 ,脚踏实地, 基本实现2020年决定设计的主要特色内容 ,着手研究目标代码生成方案;

2022年9月 ,蓄势待发, 全新的通用目的编程语言Unilang问世 ,与所有开发者们见面!

--

从业界流行的一系列方案分析,到需求、大方向的确定与设计;

从快速产出和完善整体设计的冲突,到始终尝试不同解决方案的质量优先;

从一个初步萌芽的小小想法,到一群人为之努力,所以最终得以实现;

生而为创新,今天,Unilang与你相见!

"Hello world demo.";

puts "hello, world";

自创,为何而创?

实际上,在我们决定自主设计Unilang之前,桌面应用开发方案便已经有了相当多较为成熟的选择。

Qt 代表的 C/C++ 本机应用开发方案,早已是许多 Linux 桌面系统应用的主流方案。它拥有成熟的语言标准和实现,丰富的开发资源,是最具有可移植性的工业语言的代表。不过,出了名的难以学习;冗长的项目开发周期;作为静态类型语言不具备非常“健壮”的类型系统,对开发体验改进有限等,大多数全局问题也是短时间内难以改善的。

Electron为代表的非本机和动态语言运行时为基础的开发方案,则是另一类较为主流的方案。使用这一流行的动态语言,能克服一些静态语言不够灵活的问题,但难以保障质量。由于大多数开发者难以有效优化运行时机制,也容易造成内存泄漏等问题,反而会极大影响 GUI 应用的质量和开发体验。

当然,Flutter代表的移动端解决方案正在向桌面移植,但它也具有部分其它动态语言运行时的方案类似的问题,实在称不上是一个完美的替代方案。

再从更高层的结构角度来看,不同类型的 GUI方案 繁多,却也各自存在不同的架构意义上的技术局限性。总而言之,没有任何一种现有方案能兼顾各种不同的问题,而成为没有疑义、众望所归的桌面开发首选方案。

因此,在综合分析大量方案后,我们迫切希望有这么一种语言:

它可以尽快解决以上方案中存在的痛点;

它能极大程度帮助到因语言二次开发遇到困难,而被迫放弃的开发者们;

它能够以更深刻的方式、真正地实现“通用性”;

——这就是我们选择创造Unilang的原因。

全新,何处是新?

我们将Unilang设计成为一门 现代的通用目的编程语言 ,使它以全新之姿出现,去适应更有效和灵活开发桌面环境应用,去统筹解决现有不足的新的方案中的语言部分。

那么和其他语言相比,它的新,究竟新在哪里?

  • Unilang 是图灵完备的通用计算语言。Unilang具备的创新式的语言特性,得以构建强大而易于使用的抽象。
  • Unilang 对一等对象(first-class) 的强调,使几乎任何源程序组件都更比往常意义上更容易复用——只要语言的用户愿意。
  • Unilang 的基础语言和语言扩展的底层设计,使你能以前所未有的方式、平滑地实现语言的设计的改进,并保持兼容。
  • Unilang 的资源管理模型和抽象能力,使程序在具有不同计算资源的平台上的表现默认自然地一致,且易于调整。
  • Unilang 的语言特性,决定了你可以不用拘泥于具体的语言范型。
  • Unilang 核心语言特性进行的极简设计,能帮助你能更快捷、更容易的入门。
  • Unilang 不是一门精通各种特性才能用好的语言——如果问题不是需要修改语言,无数开发者就能更集中注意力于解决语言之外的问题上。

值得一提的是,Unilang 在语言特性的层次上被设计为能支持不同的应用开发场景,但原则上对这些场景保持中立。

这意味着,它可以同时支持服务端和客户端应用的开发,不需要用户切换思维范式或者大幅更改对语言的使用习惯。

未来,邀你前来!

Unilang从今天起步,未来,也将迎接无数崭新的阶段 ——目前,我们计划将支持基于 Qt 的绑定的库,以便衔接过渡现有的一些桌面应用项目。日后也计划着在解释器的基础语言特性稳定实现后,提供带有优化的 JIT 代码生成的执行引擎。新的实现可直接替代现有解释器的部分核心,而无需改动已使用解释器的Unilang代码,获得“免费”的显著性能提升。

生而为创新! Unilang既是初生,便需要在时间的打磨下不断完善与发展。既是创新,便需要我们积极吸纳各种试验性扩展,以便利用程序语言社区的先进成果,方能快速成长为 万众期待的根技术之一 。

因此,不论是个人还是组织,不论是报告问题或者代码贡献,我们都真诚期待你能参与到Unilang建设当中,一起帮助Unilang变得更好!

集聚众人之力,不仅需要我们,也需要你!

项目地址: https://github.com/linuxdeepin/unilang

Reply Favorite View the author
All Replies
3 / 5
To page
随风乘万里
deepin
2022-09-21 04:09
#41

1.0版本发布了吗?

Reply View the author
mydragon
deepin
2022-09-21 05:22
#42

来点个赞,表示支持。语言背后更关键的是生态,语言在出发点上实际上是定义了软件开发生态发展方向的。我想深度公司提出用自己语言来做开发的想法,本质原因应该是想要摆脱C++,go等原有生态的限制,用自己更适合的方法来开发操作系统和应用。

同样的任务,用很多语言都可以实现,不同的是开发顺手的程度和实现出来的效率和稳定性的差别。对于linux来说,整个操作系统的诞生和演化,离不开C语言的贡献。如果是换另外一种语言开发Linux,那么这个系统发展到今天可能完全是另外一种样子。

所以,对于软件体系的发展,其背后的语言其实挺重要的。既然走上了这条路,决定用新的语言来构建生态,那么就认真的走下去。吃得苦中苦,方为人上人。耐得住寂寞,把语言基础方向慎重定好,尤其是前期,宁可慢一点,多体验,多对比,多实践,选出一个正确的方向。

语言的特性,会定义软件生态的方向。开发效率和运行效率,这两者之间取一个适当的平衡,是语言定义的核心。在这里举几个例子:

对比C++ 和 VB,这两者很多年曾经在编程语言界占据大半江山,C++ 运行效率高,但是开发C++软件的开发效率低,实现同样的功能,用C++语言来开发对人员素质要求要高,对开发时间要求要长,当软件规模大到一定的程度,参与人数多到一定程度的时候,实际上用C++来开发大型应用已经成为一个几乎很难实现的项目了。这一点,我们不得不认清现实。

作为反例来对比,VB当初选择的就是一个不同的方向,运行效率低一些,但是开发容易上手,开发程序效率要高得多,早年用VB做开发,经常三五天就完成一个软件投入使用,规模大一些的软件修改起来也很快。这得益于语言本身对开发模式和习惯的定义。用友当初如果不是选择VB而是用C++开发ERP软件,我想它很难有U8多年的辉煌和红利。

另外一个案例是Java和PHP。

无论从功能和实现目标上看,这两者的目标都比较相近。我在研发后期,把大量的公司项目从Java改为了PHP方向实现,主要就是看开发效率问题,同样规模的项目,用Java开发需要一年,PHP就可以三五个月完成,这对于研发团队的效率来讲,是重大的不同。不是说Java语言不好,它是我使用时间最长的计算机语言,但是Java开发生态被搞得过于注重此模式彼模式,过渡设计严重,在复用的层面上来讲,效率低下,以致于最后连Java引以为傲是性能,也最终被烂的实现拖累了。

语言的本质是工具,做一个好工具,很重要。

Reply View the author
ericneon
deepin
2022-09-21 22:08
#43

先顶再用yeah

Reply View the author
齿轮
deepin
2022-09-21 22:46
#44
种花人种花魂

由你浪?

好名字

Reply View the author
齿轮
deepin
2022-09-21 22:54
#45
lindorx

语言名字不好记,读着也拗口,还不如直接叫u语言什么的

由你浪。很好记

Reply View the author
mzhi
deepin
2022-09-22 05:46
#46
It has been deleted!
mzhi
deepin
2022-09-22 05:47
#47

好好干!早日一统江湖!

Reply View the author
st******ra@outlook.com
deepin
2022-09-22 16:50
#48

早上刚刚从公众号里看了介绍Unilang的特性的文章,又去github简单瞄了一眼,感觉很有想法很有决心。

只是有个迷惑不解的地方,是不是说Unilang的脚本文件扩展名确定是.txt了?那么,以后会不会不方便?

比如,光看扩展名区分不出普通的文本文档和Unilang的脚本文档,文档的缩略图图标也是和普通的文本文档没有区别,在文本编辑器里调整排版效果而格式化文档代码的时候不方便,等等?

聪明的你,不考虑一个独占的脚本文档扩展名吗?

Reply View the author
Death
deepin
2022-09-22 18:33
#49
jankin

这就不成c++了吗?不同领域用不同的库套不同的模板

同一套方案同一个库解决所有问题,我觉得这个不现实也不够脚踏实地

Reply View the author
Death
deepin
2022-09-22 18:37
#50
wcss2020

可是目前来讲deepin和windows的市场占有率,不能比啊

为什么一定要大众呢?小众不见得是坏事,要做小而精小而美

Reply View the author
sammy-621
deepin
2022-09-22 19:30
#51

万时长征第一步已经迈出了,语言的相关开发、调试工具配套任务仍然相当艰巨。文档所涉及的开发及调试环境搭建,仍然比较繁琐,不够友好,希望后期会改进,否则会劝退不少人。

Reply View the author
晚秋(lateautumn)
Moderator
2022-09-22 20:49
#52

深度越来越好,越来越棒了!agree

Reply View the author
BG7ZAG
deepin
2022-09-23 00:26
#53
st******ra@outlook.com

早上刚刚从公众号里看了介绍Unilang的特性的文章,又去github简单瞄了一眼,感觉很有想法很有决心。

只是有个迷惑不解的地方,是不是说Unilang的脚本文件扩展名确定是.txt了?那么,以后会不会不方便?

比如,光看扩展名区分不出普通的文本文档和Unilang的脚本文档,文档的缩略图图标也是和普通的文本文档没有区别,在文本编辑器里调整排版效果而格式化文档代码的时候不方便,等等?

聪明的你,不考虑一个独占的脚本文档扩展名吗?

.ul 怎样😄

Reply View the author
wcss2020
deepin
2022-09-23 00:57
#54
Death

为什么一定要大众呢?小众不见得是坏事,要做小而精小而美

小了厂商会加入吗?资金谁出

Reply View the author
PowerVR
deepin
2022-09-23 03:20
#55

期待

Reply View the author
Death
deepin
2022-09-23 19:08
#56
wcss2020

小了厂商会加入吗?资金谁出

按你这么说,那好多语言都会胎死腹中了,好多开源库也都死了。开源共建是一种思想,并不一定是为了钱,很多开发者开源、参与开源并不是为了钱的。

Reply View the author
jiuxian
deepin
2022-09-23 19:28
#57

这么牛逼的吗

Reply View the author
也无风雨也无晴,归去
deepin
2022-09-23 20:51
#58

感觉deepin很快就会被收购,因为你们玩的太多了,拉长,扩张,失去重心。 deepin kiss 就是deepin keep it simple and stupid

Reply View the author
也无风雨也无晴,归去
deepin
2022-09-23 20:57
#59
也无风雨也无晴,归去

感觉deepin很快就会被收购,因为你们玩的太多了,拉长,扩张,失去重心。 deepin kiss 就是deepin keep it simple and stupid

做个类似qt的东西,在c++上或者C上定义出自己的标准,规范,为我所有,而不是再发明一个语言,如果windows 的VC++ 可以说是首创,QT也按照windows的路线定制了C++成了qt。感觉deepin的思想路线出问题了。惋惜

Reply View the author
也无风雨也无晴,归去
deepin
2022-09-23 21:08
#60
也无风雨也无晴,归去

做个类似qt的东西,在c++上或者C上定义出自己的标准,规范,为我所有,而不是再发明一个语言,如果windows 的VC++ 可以说是首创,QT也按照windows的路线定制了C++成了qt。感觉deepin的思想路线出问题了。惋惜

在人力,资源,资金,有限的情况下,deepin推出了玲珑,v23,unilang,还有当前最实用的20.7,如果要继续这样扩张,希望deepin能在内部把握好。而且,只少要把20.7做成经典。

刚才看了有麒麟,人家已经免费向企业,高校批量部署,如果推行开来的话,deepin将失去了很多的机会。

Reply View the author
3 / 5
To page