自定义博客皮肤VIP专享

*博客头图:

格式为PNG、JPG,宽度*高度大于1920*100像素,不超过2MB,主视觉建议放在右侧,请参照线上博客头图

请上传大于1920*100像素的图片!

博客底图:

图片格式为PNG、JPG,不超过1MB,可上下左右平铺至整个背景

栏目图:

图片格式为PNG、JPG,图片宽度*高度为300*38像素,不超过0.5MB

主标题颜色:

RGB颜色,例如:#AFAFAF

Hover:

RGB颜色,例如:#AFAFAF

副标题颜色:

RGB颜色,例如:#AFAFAF

自定义博客皮肤

-+
  • 博客(25)
  • 问答 (1)
  • 收藏
  • 关注

原创 新手学编程,iVX应该是你最佳选择!

iVX通过“去掉程序语法,保留程序逻辑”,“图形化的逻辑表达”,以及“面向组件编程”,大大缩短了编程的“学习路径”和“开发路径”。由于现在很多的编程学习,都是某一个“局部”的开发能力,因此,开发者想要独立完成一个项目,对知识和能力要求就很高,因此才有了一种叫“全栈工程师”的程序员。众多的编程语言、框架、工具,复杂的开发流程和环境,各种背景知识的学习,这个都给编程学习者带来了巨大的困扰,很多人不得不中途被劝退。”,根据我自身的理解,“编程就是,利用现有数据,通过计算机建模来解决问题的过程。

2024-03-08 14:16:01 193

原创 为什么说开源也不能解决低代码的核心问题

另外,由于拼凑的功能的缘故,感觉整体产品融合性不好,怎么说呢,看上去这个功能也有,那个功能也有,但是操作起来就是不顺手!举个例子,就像我花钱做Windows的应用开发,那我肯定关心这个应用的代码,而不是Windows的代码一样。就算开源平台后面依托了一个企业,去帮你做定制,短时间内也不一定可以满足“企业需求”,另外,由于是开源产品,可控性还是会差一些。朋友的公司需要采购低代码平台,然后咨询我“开源的低代码平台”怎么样?这是我调研的结果,界面都差不多,使用的库和技术也非常接近,架构几乎一样。

2024-03-01 09:32:55 189

原创 低代码的核心问题:其实是方法论的问题!

有时候是没有办法,基于当时的认知和技术,以及硬件环境,只能做当时的事情,这个可以理解,但是如果技术等各方面条件具备,还一大帮子人往错误的方向上努力,这就是一个问题了!但是“低代码”似乎是一个例外,眼看着无数产品都在错误的路线上越走越远~~~特别是在国内这种“一窝蜂”的大环境下,是对资源的极大浪费!无论产品是挤在“开发态”还是“运行态A”里面,用户用起来都会“拧巴”。现在低代码产品的核心问题:就是方法论的问题,多数就是底层的方案存在重大瑕疵,根本无法通过进一步的迭代来修正问题。其实这个低代码就是这么来的。

2024-03-01 09:31:41 228

原创 iVX对编程最大的贡献是什么?

到时候,我会拿着以前写的代码给外孙讲“以前我们做过一件事儿,叫Coding...”当然要做完备的“图形化编程语言”,还需要很多别的东西,这里面有两个东西最关键:一是:“面向组件”编程,也就说“一切皆组件”,组件作为程序的最小颗粒度(这个是没有问题的哈,前端、后台、变量...所有的都可以抽象为组件,现有的可以用,也可以自给自足);早期的编程语言发明者或程序员都是计算机领域专家,他们很厉害,但是那个时候设备还很落后,连操作系统都没有图形界面,更不可能想到用“图形化”的方式来编程了,特别是作为最主要的编程手段。

2024-02-28 12:17:38 226

原创 iVX虽然是图形化编程,但“我们不一样”

因此,本身图形化编程就是难度很大,赌性十足的项目方向。”,这个和产品本身的设计有很大关系,但本身并没有什么限制,原则上所有的逻辑过程都可以“封装和抽象”,都可以通过图形化方式来表达。(2)一些复杂的应用,例如电商系统、MES(工业)、ERP(工业)、CRM、OA、通信/客服、游戏、智慧城市/iot、原生应用等iVX都有很多成功案例,一些项目甚至生成上千万行应用。(2)近代的,还在使用的“用于数据流编程的Labview/NodeRed”,拖拽画图,强大直观,效率有所提升(在数据处理和测试等领域的编程)

2024-02-28 12:07:50 690

原创 如何选择“低代码”、“无代码”和“图形化编程语言”?

但是,由于“编程语言”本身是面向“开发者设计”,而非“面向企业设计”,因此,最多就是和Ideal J一样收IDE的license费用,不太可能收最终用户的费用(因为原则上完全不知到最终有多少用户,运行时应该是“未知”的)。如果从技术升级,中台建设(我个人其实还是挺中台的,只是中台要求较高,如果用图形化编程可以试一下,成本会降低很多),降本增效来讲,“图形化编程语言”应该是不错的选择,效率上相比代码提升明显,能力边界和代码开发非常接近。在我看来,低代码平台,不能算是一种“新技术”,而是一种为“

2024-02-28 11:58:58 264

原创 低代码未来趋势

与此同时,低代码应用开发趋势调查的数据显示,70%的用户在1个月内或更短时间内学会了低代码,73%的用户在3个月内或更短时间内开始开发应用。如今,低代码开发平台是帮助实现快速应用开发和快速部署的关键战略的一部分。由于低代码和无代码平台,越来越多没有编程背景的人离技术更近,无需花费数年学习如何编码即可创建定制应用程序。然而,对于工作流程管理或数据分析等更简单的应用程序,由于用户体验的提高,非开发人员也可以创建。根据埃森哲的数据,87%的公用事业高管认为技术的民主化对于激发组织内的创新至关重要。

2024-02-28 11:29:09 193

原创 低代码平台的发展历史是什么样的?

因此,经验丰富的开发人员不断寻找加速产值时间的方法,通常依赖于预构建的模块和平台,以更快地构建应用程序,几乎更重要的是,直接与用户互动的地方。它的制作者将Retool称为内部工具的平台,并利用焕然一新的设计和强大的分销引擎,在2017年推出后的几年内成为了一家价值数十亿美元的公司。MDD的优势之一是它通常是平台无关的,可以为许多不同的应用程序创建代码。低代码工具是RAD方法的一个合乎逻辑的结果,因为它们实现了更快的开发,提供了预构建的组件,并且通常具有拖放界面,允许用户快速拼凑可工作的应用程序。

2024-02-28 11:28:18 623

原创 低代码开发的历史

因此,经验丰富的开发人员不断寻找加速产值时间的方法,通常依赖于预构建的模块和平台,以更快地构建应用程序,几乎更重要的是,直接与用户互动的地方。它的制作者将Retool称为内部工具的平台,并利用焕然一新的设计和强大的分销引擎,在2017年推出后的几年内成为了一家价值数十亿美元的公司。这些界面包括不同的设置,可以影响正在构建的组件的布局或逻辑,而无需使用代码。低代码工具是RAD方法的一个合乎逻辑的结果,因为它们实现了更快的开发,提供了预构建的组件,并且通常具有拖放界面,允许用户快速拼凑可工作的应用程序。

2024-02-28 11:10:39 294

原创 低代码开发是怎样的?

因此,经验丰富的开发人员不断寻找加速产值时间的方法,通常依赖于预构建的模块和平台,以更快地构建应用程序,几乎更重要的是,直接与用户互动的地方。它的制作者将Retool称为内部工具的平台,并利用焕然一新的设计和强大的分销引擎,在2017年推出后的几年内成为了一家价值数十亿美元的公司。这些界面包括不同的设置,可以影响正在构建的组件的布局或逻辑,而无需使用代码。低代码工具是RAD方法的一个合乎逻辑的结果,因为它们实现了更快的开发,提供了预构建的组件,并且通常具有拖放界面,允许用户快速拼凑可工作的应用程序。

2024-02-28 11:08:58 306

原创 图形化编程语言/低代码生成的代码:理论上哪些操作可行?哪些不可行?

结论,即使是iVX这样的低代码平台,也会强调,导出完整代码支持二次开发和编译,但是仍然系统开发者在iVX IDE中二次开发,之后再导出,按这个流程来维护代码,而不希望直接导出代码,直接二次修改,因为这样就会出现一个独立的分支,且该分支将无法和iVX IDE 主干进行合并。这里的“不可行”并不是理论上做不到,而是不会这么去设计,如果二次手工修改代码还能导入低代码图形IDE,这就意味着两边是完全等价的,意味着逻辑和过程没有优化,信息是对等的。生成代码,可以二次修改,再编译,再独立部署 —— 可行!

2024-02-27 18:32:26 409

原创 低代码开发真的存在悖论吗?

就像Windows开源了,但是上面的应用没有代码,最终企业还是去维护应用,而不是去维护Windows,哪怕这个企业真能维护Windows,也成本太高,有违低代码降低成本的初衷!由于种种原因(其实主要是强行引入完整的BPM解决方案造成的),多数低代码平台设计了很多开发工具,有前端的、工作流的、画逻辑的、数据可视化、表格的、表单的... ,里面时不时就嵌入点代码,反正要程序员才能看懂的😂。(关于低代码的提法是否科学,我们就不讨论了,其实我觉得这种叫法本身就不科学,“代码越来越少”一定是编程演进的方向。

2024-02-27 18:31:47 306

原创 低代码无法走出的困境——低代码平台的三大悖论!

而且这种“锁定”机制有一点像当年的Oracle,是“不断积累”的锁定(不像SaaS产品切换起来相对比较容易),低代码平台由于需要把研发资源不停在平台上积累,所以一旦大规模投入之后,由于无法生成源代码(或无法生成完整源代码),企业就很难脱离平台,这就是所谓的平台锁定。如果是简单应用,那么“SaaS”就已经很好使了,没有必要引入“低代码”(之所以叫低代码,就是开发过程中还是很难避免“代码”的)。这也是这么多年“低代码”很难快速发展的核心“阻碍”,没有企业愿意重蹈覆辙,让当年的“Oracle模式”再次上演。

2024-02-27 18:22:49 120

原创 还有戏没戏?低代码的天坑与对策!

这个的最大阻碍来自“新进者”,也就是新的开发者,由于学习周期和现有程序员几乎一样,甚至还要多学一个低代码平台的框架,以致“学习成本”太高,自身的收益又有限(如果只是加快了某些场景下系统的开发效率),所以并不被新进开发者开好。具体哪个好,我就不评价了,大家都可以去试一下,但是我可以把一些我认为合理的评价标准给列出来,大家自己去体验。首先,低代码aPaaS平台不同于传统的SaaS平台,aPaaS低代码需要不停的研发投入的,而SaaS是“用完即走”,实在不行,还可以把SaaS相关数据下载下来,然后打包带走。

2024-02-27 18:21:31 391

原创 iVX和低代码有什么关系?

iVX和代码是“充分非必要”的关系,代码在iVX中的各个地方都可以使用,包括:自定义组件、JS函数、CSS、HTML、Java、SQL、以及各种SDK。本申明的目并不是评判“谁高谁低”,每一种技术都有其符合自身使用的场景。低代码也有很多适合的使用场景,也许在其适合的场景中,低代码还要更便捷一些。iVX涉及编程语言设计、编译器/解释器、各种框架/语义/语法转化、图形化IDE、iVX只负责生成代码,和运行时资源解耦(运行时资源由“公有云”“私有云”提供)具备“代码生成能力”,则能“往前兼容”,

2024-02-27 18:19:41 211

原创 有没有人能把低代码说得通俗易懂一点?

在这个框架下,如果程序员想要实现平台无法完成的功能,而且不能添加代码,这意味着你需要联系平台方来实现这个功能,沟通会耗费时间,而且还需要支付额外费用,这可能会让人感到不满。也有一些少部分的平台,比如iVX,可以通过编写代码来完成非标准需求(根据我个人的需求,我在所有找到的低代码平台中都进行了体验,最终选择了iVX,因为它允许为非标准需求编写代码。如果还有其他平台,请随时纠正!),并且能够导出可读可修改的代码。因此,整个项目都可以由开发者自行完成,无需与平台方联系以进行定制或沟通需求,从而降低了沟通成本。

2024-02-27 18:14:29 380

原创 不能真“生成代码”的“低代码”平台,不可能真正获得程序员的认可

注意,由于语言本身的限制,很容易被混淆,这里的应用是开发的“单个应用实例”,也就是“开发了什么就生成什么”,不是一大堆框架的代码。现在基本上比较有名的,大部分都列在上面,大部分还是我们称之为“企业内部应用快速开发框架”的产品,这样产品可能有近200款,还有一些开源的例如,jeecg\若依\taskbuilder,做得还不错的,能够生成部分内部模块代码或者打包一个内部环境格式的文件,但是绝大部分都不能“真正生成代码”,像编程语言那样生成代码。当然,还有一些页面生成型的,多数都是纯前端的,所以就没有列出来。

2024-02-27 18:12:03 264

原创 不能“生成代码”的低代码平台,程序员不会用!那能生成可读可改代码的低代码平台你用吗?

对于这样的平台,很多程序员有一个“本能的抗拒”,当然最主要的还是担心如果技术被锁定在某一个低代码平台,会不会影响将来“自身的技术提升”,甚至会不会影响自己的收入?总之,只给程序员助力,不要去挑战程序员,应该是比较理性的做法。其实,对于这样的平台,很大程度上已经不用手写任何代码,包括二次开发都可以在平台上通过拖拽配置的方式完成,但是,为程序员保持“代码”这种接口,很重要!每个企业,由于长时间的研发和演进,往往都形成了自己的研发体系和自有的研发资源/数据资源,这些资源如何在“低代码平台”上使用也是一个问题。

2024-02-27 18:06:59 167

原创 程序员不会用现在的“低代码”,包括开源低代码平台

更像是一个“空中楼阁”,只能进不能出那种,由于无法生成代码,因此一旦选择某一“低代码平台”,基本上等于把身家性命都押上了,一旦“平台有事”,基本上会“颗粒无收”,甚至影响现有的运行业务。程序员只相信“代码”,哪怕是自动生成的代码,也是可以接受的。现在的低代码平台,本身的缺点是很明显的(平台锁定+程序员抵制),将这种模式开源之后,再在企业内部迭代,其实意义不大,很容易就让一个企业掉进一个“死胡同”里,“低代码”本身模式的缺陷,不太可能因为企业内部的迭代而根本改变。1. 调整一套生成应用的框架,太复杂。

2024-02-27 18:02:03 347

原创 编程范式的演进过程?一图看懂低代码/图形化编程/AI编程联系和区别

第三类:代码生成型,比较典型的就是“iVX”和“CodeWave”,这一类其实并不算标准意义上的“低代码”,其实提出低代码概念的公司Mendix/Outsystems 机构Gartner等,仍然是站在企业数字化转型的角度思考,并没有站在“编程技术”演进的高度来考虑这个问题。低代码概念本身不算“编程语言”,甚至也不能算“新的编程范式”,只能算是“企业服务”的产品范畴,是企业服务在SaaS和编程可视化上的一种结合的产物,在一些特定场景有明显的效率优势,但也有其明显的局限性,这将限制其自身发展。

2024-02-27 17:59:18 739

原创 为什么现在的编程方式是代码?有没有可能“非代码”方式编程?

在编程语言设计上,现在绝大部分和早起编程语言一样,都是“纯文本”的(这和当初的屏幕分辨率、内存、算力...都有关系 ),随后就产生了“纯文本”的编程过程,这也就是我们所说的Coding...代码也就产生了,并且沿用至今。程序(Programming),就是把 01001101这样表达和一个具体问题的解决联系起来,就是“通过计算机的算力来构造具体问题的解决模型”,也就是我说的“建模”。有了编程的这个需求,大师和先贤就做了一种叫做“编程语言”的东西,后面就有了“一代”、“二代”、“高级编程”语言。

2024-02-27 17:54:08 157

原创 面对要团灭“程序员”岗位的OpenAI,程序员如何自处?

从前,我在各个平台看到很多程序员的对低代码所有产品的“谩骂”,很多人甚至都没有去使用一下,更没有对低代码产品进行认真的分类和分析,以点带面,以偏概全。前面提到的图形化编程语言(生成代码的低代码平台),可以去尝试一下,生成代码质量高,可以很快让你进入开发的状态,快速开发出目标产品,学以致用。现在的编程语言代码,AI学习就和学习其它文本一样,没有办法实际“运行”,去看结果,也就没有办法建立“代码和运行时以及运行后的逻辑映射”,这也导致代码的学习异常困难;例如Scratch,iVX等。

2024-02-27 17:49:13 250

原创 低代码/无代码的最核心技术其实是“逻辑可视化”?

前面我有讲过“面向模型编程”和“面向组件编程”,都是减少“代码量”的有效途径。“面向模型”或者说“面向引擎”编程,通常颗粒度会比较大,灵活性会有一些限制,对于一些较为直观的模型,业务人员是可是应用的;而“面向组件编程”颗粒度很小,可以提供类似编程语言的灵活性,产品的设计难度会大一些,这种产品会更适合研发人员使用。

2024-02-27 17:42:53 942

原创 编程语言:如果不被AI干掉,将会进化到“图形化”阶段

后来,有过很多图形化尝试,有一些也做得非常不错,例如Delphi,VisualBasic,Visual C++,C++Builder,J Builder... ,但是这些其实都是把图形化作为编程的“辅助手段”,而iVX则是把图形化作为编程“核心手段”。当然要做完备的“图形化编程语言”,还需要很多别的东西,这里面有两个东西最关键:一是:“面向组件”编程,也就说“一切皆组件”,组件作为程序的最小颗粒度(这个是没有问题的哈,前端、后台、变量...所有的都可以抽象为组件,现有的可以用,也可以自给自足);

2024-02-27 17:39:25 218

原创 全中文+图形化:国产编程语言来了!

后来,有过很多图形化尝试,有一些也做得非常不错,例如Delphi,VisualBasic,Visual C++,C++Builder,J Builder... ,但是这些其实都是把图形化作为编程的“辅助手段”,而iVX则是把图形化作为编程“核心手段”。当然要做完备的“图形化编程语言”,还需要很多别的东西,这里面有两个东西最关键:一是:“面向组件”编程,也就说“一切皆组件”,组件作为程序的最小颗粒度(这个是没有问题的哈,前端、后台、变量...所有的都可以抽象为组件,现有的可以用,也可以自给自足);

2024-02-27 17:34:45 307

空空如也

空空如也

TA创建的收藏夹 TA关注的收藏夹

TA关注的人

提示
确定要删除当前文章?
取消 删除