1.0版本发布了吗?
来点个赞,表示支持。语言背后更关键的是生态,语言在出发点上实际上是定义了软件开发生态发展方向的。我想深度公司提出用自己语言来做开发的想法,本质原因应该是想要摆脱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引以为傲是性能,也最终被烂的实现拖累了。
语言的本质是工具,做一个好工具,很重要。
先顶再用
由你浪?
好名字
语言名字不好记,读着也拗口,还不如直接叫u语言什么的
由你浪。很好记
好好干!早日一统江湖!
早上刚刚从公众号里看了介绍Unilang的特性的文章,又去github简单瞄了一眼,感觉很有想法很有决心。
只是有个迷惑不解的地方,是不是说Unilang的脚本文件扩展名确定是.txt了?那么,以后会不会不方便?
比如,光看扩展名区分不出普通的文本文档和Unilang的脚本文档,文档的缩略图图标也是和普通的文本文档没有区别,在文本编辑器里调整排版效果而格式化文档代码的时候不方便,等等?
聪明的你,不考虑一个独占的脚本文档扩展名吗?
这就不成c++了吗?不同领域用不同的库套不同的模板
同一套方案同一个库解决所有问题,我觉得这个不现实也不够脚踏实地
可是目前来讲deepin和windows的市场占有率,不能比啊
为什么一定要大众呢?小众不见得是坏事,要做小而精小而美
万时长征第一步已经迈出了,语言的相关开发、调试工具配套任务仍然相当艰巨。文档所涉及的开发及调试环境搭建,仍然比较繁琐,不够友好,希望后期会改进,否则会劝退不少人。
深度越来越好,越来越棒了!
早上刚刚从公众号里看了介绍Unilang的特性的文章,又去github简单瞄了一眼,感觉很有想法很有决心。
只是有个迷惑不解的地方,是不是说Unilang的脚本文件扩展名确定是.txt了?那么,以后会不会不方便?
比如,光看扩展名区分不出普通的文本文档和Unilang的脚本文档,文档的缩略图图标也是和普通的文本文档没有区别,在文本编辑器里调整排版效果而格式化文档代码的时候不方便,等等?
聪明的你,不考虑一个独占的脚本文档扩展名吗?
.ul
怎样😄
为什么一定要大众呢?小众不见得是坏事,要做小而精小而美
小了厂商会加入吗?资金谁出
期待
小了厂商会加入吗?资金谁出
按你这么说,那好多语言都会胎死腹中了,好多开源库也都死了。开源共建是一种思想,并不一定是为了钱,很多开发者开源、参与开源并不是为了钱的。
这么牛逼的吗
感觉deepin很快就会被收购,因为你们玩的太多了,拉长,扩张,失去重心。 deepin kiss 就是deepin keep it simple and stupid
感觉deepin很快就会被收购,因为你们玩的太多了,拉长,扩张,失去重心。 deepin kiss 就是deepin keep it simple and stupid
做个类似qt的东西,在c++上或者C上定义出自己的标准,规范,为我所有,而不是再发明一个语言,如果windows 的VC++ 可以说是首创,QT也按照windows的路线定制了C++成了qt。感觉deepin的思想路线出问题了。惋惜
做个类似qt的东西,在c++上或者C上定义出自己的标准,规范,为我所有,而不是再发明一个语言,如果windows 的VC++ 可以说是首创,QT也按照windows的路线定制了C++成了qt。感觉deepin的思想路线出问题了。惋惜
在人力,资源,资金,有限的情况下,deepin推出了玲珑,v23,unilang,还有当前最实用的20.7,如果要继续这样扩张,希望deepin能在内部把握好。而且,只少要把20.7做成经典。
刚才看了有麒麟,人家已经免费向企业,高校批量部署,如果推行开来的话,deepin将失去了很多的机会。
2022年9月,deepin正式公开了自研全新通用目的编程语言——Unilang!
回顾过去,倍觉光阴荏苒:
2020年4月 ,这一年,我们决定开发自己的语言 ,进一步往上做GUI框架;
2020年6月 ,想法成型,经调研分析后,我们创建Unilang仓库 ,提交了第一行代码;
2021年3月 ,脚踏实地, 基本实现2020年决定设计的主要特色内容 ,着手研究目标代码生成方案;
2022年9月 ,蓄势待发, 全新的通用目的编程语言Unilang问世 ,与所有开发者们见面!
--
从业界流行的一系列方案分析,到需求、大方向的确定与设计;
从快速产出和完善整体设计的冲突,到始终尝试不同解决方案的质量优先;
从一个初步萌芽的小小想法,到一群人为之努力,所以最终得以实现;
生而为创新,今天,Unilang与你相见!
自创,为何而创?
实际上,在我们决定自主设计Unilang之前,桌面应用开发方案便已经有了相当多较为成熟的选择。
Qt 代表的 C/C++ 本机应用开发方案,早已是许多 Linux 桌面系统应用的主流方案。它拥有成熟的语言标准和实现,丰富的开发资源,是最具有可移植性的工业语言的代表。不过,出了名的难以学习;冗长的项目开发周期;作为静态类型语言不具备非常“健壮”的类型系统,对开发体验改进有限等,大多数全局问题也是短时间内难以改善的。
Electron为代表的非本机和动态语言运行时为基础的开发方案,则是另一类较为主流的方案。使用这一流行的动态语言,能克服一些静态语言不够灵活的问题,但难以保障质量。由于大多数开发者难以有效优化运行时机制,也容易造成内存泄漏等问题,反而会极大影响 GUI 应用的质量和开发体验。
当然,Flutter代表的移动端解决方案正在向桌面移植,但它也具有部分其它动态语言运行时的方案类似的问题,实在称不上是一个完美的替代方案。
再从更高层的结构角度来看,不同类型的 GUI方案 繁多,却也各自存在不同的架构意义上的技术局限性。总而言之,没有任何一种现有方案能兼顾各种不同的问题,而成为没有疑义、众望所归的桌面开发首选方案。
因此,在综合分析大量方案后,我们迫切希望有这么一种语言:
它可以尽快解决以上方案中存在的痛点;
它能极大程度帮助到因语言二次开发遇到困难,而被迫放弃的开发者们;
它能够以更深刻的方式、真正地实现“通用性”;
——这就是我们选择创造Unilang的原因。
全新,何处是新?
我们将Unilang设计成为一门 现代的通用目的编程语言 ,使它以全新之姿出现,去适应更有效和灵活开发桌面环境应用,去统筹解决现有不足的新的方案中的语言部分。
那么和其他语言相比,它的新,究竟新在哪里?
值得一提的是,Unilang 在语言特性的层次上被设计为能支持不同的应用开发场景,但原则上对这些场景保持中立。
这意味着,它可以同时支持服务端和客户端应用的开发,不需要用户切换思维范式或者大幅更改对语言的使用习惯。
未来,邀你前来!
Unilang从今天起步,未来,也将迎接无数崭新的阶段 ——目前,我们计划将支持基于 Qt 的绑定的库,以便衔接过渡现有的一些桌面应用项目。日后也计划着在解释器的基础语言特性稳定实现后,提供带有优化的 JIT 代码生成的执行引擎。新的实现可直接替代现有解释器的部分核心,而无需改动已使用解释器的Unilang代码,获得“免费”的显著性能提升。
生而为创新! Unilang既是初生,便需要在时间的打磨下不断完善与发展。既是创新,便需要我们积极吸纳各种试验性扩展,以便利用程序语言社区的先进成果,方能快速成长为 万众期待的根技术之一 。
因此,不论是个人还是组织,不论是报告问题或者代码贡献,我们都真诚期待你能参与到Unilang建设当中,一起帮助Unilang变得更好!
集聚众人之力,不仅需要我们,也需要你!
项目地址: https://github.com/linuxdeepin/unilang