Visual Basic不可能消失(From Yesky)

2024-03-12 15:48
文章标签 visual 消失 可能 basic yesky

本文主要是介绍Visual Basic不可能消失(From Yesky),希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

一直以来,学者们都预言Visual Basic的未来具有不确定性,这显示出人们完全误解了促成某种编程语言流行的原因,同时它还忽视了Visual Basic自身独特的精神。
 
  近十年以来人们一直预言Visual Basic会消亡,但即使在Visual Basic.NET出现后,一切仍然没有发生变化。从最近的报道来看,VB.NET的未来受到了它的兄弟语言C#的挑战。即使过了这么多年,人们还是无法理解VB——以及现在的VB.NET——仍然是一种世界上最流行的编程语言。的确,某些VB程序员会转向C#、Java或Delphi,但是这些语言所考虑的变革因素却突出了一个事实——它们都是朝着易用和快速开发的方向演化的,而这些特性正是Visual Basic所发明和倡导的。无论发生了什么事情,VB这种语言、它的灵魂都征服了编程世界,并且将继续存在。实际上,VB所倡导的理念,还从来都没有像现在这么活跃过。

显著的成功

  Visual Basic早期版本并没有引起巨大的反响,但是这种语言却是革新的,并且作为一种新的编程范例(paradigm)吸引了相当大的注意力,因为它允许程序员可视化地建立窗体(form)。人们第一次可以通过把控件拖放到设计界面上,不需要经过其它语言所需要的冗长的编辑-编译-测试周期就可以看到程序的外貌。

  Visual Basic通过执行终止运行(end-run)进一步缩减了编辑-编译-测试周期。传统的VB类似于很多早期的BASIC实现,它是一种解释语言,你可以在运行时(runtime)编辑VB代码。即使程序还在运行之中,VB集成开发环境(IDE)也会立即应用大多数代码改变,这让你能够在调试程序中逐步执行某段代码、查找错误、改正错误并重新测试代码,而这一切都不需要停止程序来重新编译。这种称为“编辑后继续运行(edit and continue)”的特性使VB的生产效率大幅度提高,超越了旧的编辑-编译-测试的开发模式。

  程序员喜欢拖放控件的能力,但是它们并没有满足于内建的(built-in)控件。幸运的是,微软制订了一种架构(architecture),程序员群体可以使用它来建立控件。很快地,企业开发人员建立了数百个“VBX”控件(以及后来的ActiveX控件),它覆盖了整个工业领域,同时还把可重复使用(reusable)的代码的观念提升到了一个新的层次。

  Visual Basic同时还是第一种流行的用于通用目的的编程语言,它提供了真正的集成的数据库访问。通过微软数据访问对象(DAO)技术,在VB中处理关系数据库变得非常简单,以至于在很多情况下开发者根本不需要了解下层关系数据库工作方式的任何信息,他们可以把感知数据库的(database-aware)控件拖放到窗体上。即使对于更加高级的开发者来说,DAO(和它的继承者,例如RDO、ADO和现在的ADO.NET)也使生产效率大幅度提高了。

  在第三版中,VB变得稳定和快速。它拥有当时可以使用的最好的IDE,同时数百万兼职程序员都可以理解它。VB迅速成为世界上最流行的应用程序编程语言,并且无论出现它会消逝的预言还是语言本身的实质改变,它都维持着自己的位置。

  Visual Basic一直保持着流行的原因在于它提供了开发者群体最关心的六个要素:

  1. 类似Basic的、大小写不敏感(case-insensitive)的语法

  2. 可视化设计的能力

  3. 带有集成的调试程序的伟大的集成开发环境

  4. 编辑后继续运行(Edit-and-continue)

  5. 多种便宜的、牢固的后续控件

  6. 简单的、集成的数据库支持

  其它的一些语言也提供了这些特性的子集,但是没有任何一种语言成功地占领VB所占有的巨大市场。

  其它厂商长期垂涎于VB的开发人员基础,并且作出了巨大的努力,希望引诱VB开发者迁移到其它的平台。例如,Borland的Delphi语言提供了VB所提供的一切东西,除了类似BASIC的语法和编辑后继续运行。实际上Delphi提供的能力比VB提供的能力要多一些。例如,它的速度更快。Delphi代码执行的速度本质上与C++的速度相同。Delphi还提供了用于自己的Dbase和Interbase桌面数据库的本地感知数据库的控件。Delphi的未来版本甚至于提供了ADO包装。

  但是Delphi使用了对象Pascal语言基础而不是BASIC核心,而这种特性的改变妨碍了它的广泛采用。无论速度是否更快或提供了真正的面向对象编程(OOP)能力——简而言之,就是基于COM程序包的VB.NET的所有特性——Delphi从来都不是VB普及的重要竞争者。

C#能代替Visual Basic吗?

  微软意识到有些特性使得VB普及起来,并把这些特性包含到了VB.NET中。可是C#从来都不是作为“VB杀手”来设计的。其实,C#更像是用于吸引C++和Java的开发者。C#提供了类似C的语法,与C++和Java都很相似。然而,它丢失了六条特性中的第一条——类似BASIC的语法。尽管对于有些开发者来说语法并不重要,但是对于其它一些开发者来说这太重要了。

  此外VB和目前的VB.NET都不是大小写敏感的语言。例如“Email”和“EMail”是相同的变量。在C、C++、Java、Jscript和其它类似C的语言中,改变大写是错误的,EMail和Email不是相同的变量。

  C#的确拥有可视化的设计和简单的、集成的数据库支持,并且最终会拥有可供选择的巨大的后续控件库——但是这个控件库与VB.NET开发者所拥有的控件库相同。

  C#的IDE还需要更多的东西。即使C#与VB.NET共享IDE,该IDE也分别与每种语言相对应。例如,VB.NET中的Intellisense就比C#中的好多了,你可能猜到了——C#中的Intellisense是大小写敏感的。为什么在辅助人们查找未知信息和不记得的信息的搜索特性中实现大小写敏感性是我无法理解的。更糟的是,它的大小写敏感性还是不一致的。

  没有人否认C#语法更加简练。如果你讨厌输入并且没有使用Intellisense的代码填充能力,或者你已经在使用C语言语法,那么你就应该使用C#。但是这并不意味着C#将最终代替VB.NET。

  更大的问题是VB.NET是否会代替VB。其中一个问题是VB.NET也没有包含VB的所有特性。特别是VB.NET丢失了编辑后继续运行、长期许诺、继续交货的特性,而它们将成为VB程序员迁移到.NET版本关键的影响因素。

  代码的不兼容性是阻碍迁移的另一个因素。微软还没有使代码从VB迁移到VB.NET足够简单。尽管VB.NET语法与传统的VB语法非常类似,但却不是相同的。它不仅是语法的改变,同时还是对框架的增添。VB到VB.NET的升级向导不仅现在,而且将来可能也永远不能十分智能化地无缝地迁移所有的应用程序。

  同时,大多数VB程序员并没有大型的垂直应用程序需要迁移,他们要么编写了小型应用程序,重新进行编写并不昂贵,要么计划用VB维护已有的应用程序,同时用.NET建立新的应用程序。对于这类大多数程序员来说,语言的不同是受到欢迎的,从而使VB.NET成为传统VB的唯一可能的真正威胁。

VB.NET会超越Windows平台吗?

  有趣的是,Java阵营的一些进步好像对Visual Basic编程也有影响。由于忽略了建立语言的跨平台版本,微软在充分利用这些语言的大众化方面已经失败了。这意味着Sun公司的Java由于拥有在任何平台上运行的能力,将会领导跨平台领域,而这会带来实际的商业利益——在服务器领域。但是接着Sun也失败了,它由于忽略了提供类似VB的GUI开发环境,因而无法利用Java的大众化,结果是Java成为了服务器端、非GUI应用程序市场之王,而VB、C++和.NET统治着桌面平台。

  但是情况不会永远不变,这需要感谢IBM的Eclipse项目,Java开发人员现在也可以建立容易响应的Windows应用程序,完全可以与微软编程语言编写的应用程序相媲美。并且Sun已经声明在Rave中将为Java开发者提供简单化的RAD特性。

  挑战这种趋势的都是一些忙于把.NET框架组件迁移到Linux和Unix上的开放和共享源代码的项目。如果这些项目取得成果,.NET开发者将最终获得与Java类似的跨平台能力。这些趋势将导致一些有趣的转换和变革,但是它们都没有直接威胁到Visual Basic。

保持多种选择

  Visual Basic.NET是Visual Basic真正的继承者,因为目前没有一种语言能像VB.NET一样匹配VB的特性集合。但是仍然存在抱怨者——一旦你决定离开传统的VB,就根本不用关心自己学习了那种语言。如果你决定迁移到VB.NET,你会发现它是完全可行的,如果觉得不太合适,也可以使用C#或J#编程。

  即使你决定完全与微软断绝关系并切换到Java或Delphi,你也会发现在学习了这些语言和框架之后,切换到.NET不是十分困难。除了少数的例外,所有这些编程语言背后的思想都是相同的。它们之间的语法和IDE的差别远远大于概念和能力的差别。

结束语

  VB的未来并没有不确定性。VB是一组特性的集合。所有流行的语言都在朝着适应这些特性的方向转变,而这些特性的倡导者是传统的Visual Basic,并且在Visual Basic.NET中得到了进一步的发展。不论语法、平台和框架是否相同,Visual Basic的精神都将继续存在。

这篇关于Visual Basic不可能消失(From Yesky)的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/801771

相关文章

如何在Visual Studio中调试.NET源码

今天偶然在看别人代码时,发现在他的代码里使用了Any判断List<T>是否为空。 我一般的做法是先判断是否为null,再判断Count。 看了一下Count的源码如下: 1 [__DynamicallyInvokable]2 public int Count3 {4 [__DynamicallyInvokable]5 get

找出php中可能有问题的代码行

前言 当你发现一个平时占用cpu比较少的进程突然间占用cpu接近100%时,你如何找到导致cpu飙升的原因?我的思路是,首先找到进程正在执行的代码行,从而确定可能有问题的代码段。然后,再仔细分析有问题的代码段,从而找出原因。 如果你的程序使用的是c、c++编写,那么你可以很容易的找到正在执行的代码行。但是,程序是php编写的,如何找到可能有问题的代码行呢?这个问题就是本文要解决的问题。 背景

颠覆你的开发模式:敏捷思维带来的无限可能

敏捷软件开发作为现代软件工程的重要方法论,强调快速响应变化和持续交付价值。通过灵活的开发模式和高效的团队协作,敏捷方法在应对动态变化和不确定性方面表现出色。本文将结合学习和分析,探讨系统变化对敏捷开发的影响、业务与技术的对齐以及敏捷方法如何在产品开发过程中处理持续变化和迭代。 系统变化对敏捷软件开发的影响 在敏捷软件开发中,系统变化的管理至关重要。系统变化可以是需求的改变、技术的升级、

力扣 797. 所有可能路径【DFS】

1. 题目 2. 代码 DFS , 直接见代码 class Solution {public:vector<int> path;vector<vector<int>> res; // 结果集void dfs(vector<vector<int>>& graph, int cur, int n){// 找出所有从节点 0 到节点 n-1 的路径// 下标从 0 开始的if (

【Visual Studio 报错】未加载 wntdll.pdb(一种可行的解决办法)

调试程序时,会出现下面这个报错 分析原因: 出现未加载 wntdll.pdb 报错大概率是你的指针使用错误 ,比如使用野指针、越界访问、或者堆区空间释放方式错误等。 这里以 堆区空间释放方式错误 为例子 1、堆区开辟的数组空间使用 delete 释放 // 堆区开辟的数组空间使用 delete 释放int* p = new int[10];delete p; 正

你读文献的方式可能错了!掌握这些技巧,让阅读事半功倍!

我是娜姐 @迪娜学姐 ,一个SCI医学期刊编辑,探索用AI工具提效论文写作和发表。 科研新手如何精读一篇论文? 很多科研新手,一上来就疯狂下载几十上百篇文献。囫囵吞枣看完了,还是什么都不知道,大脑一片空白。究竟该如何读文献收获最大? 大佬说,要积极阅读、频繁阅读。 什么是积极阅读? 相比被动阅读,积极阅读是指在阅读之前准备好问题、设置阅读目标、保持批判性,收获更多、进步更大的一种阅读

查看Excel 中的 Visual Basic 代码,要先设置excel选项

1. excel VB的简单介绍 百度安全验证 2.excel选项设置 excel表格中在选项->自定义功能区域,选择开发工具,visual baisc/查看代码,即可看到代码。 3.excel已经设置,可以直接查看

机器人可能会在月球上提供帮助

登月是我们这个时代最具标志性的事件之一,这可能还算轻描淡写了:这是我们迄今为止在物理上探索得最远的一次。我听过一些当时的老广播,它们可以让你想象出这次航行的重要性。 现在,研究人员表示,我们可能很快就能重返月球,甚至可能很快就会有人类任务前往火星。 火星。艺术家:NASA 这次会有什么不同呢? 有一点是确定的:机器人将大力协助—— 非常多。 在麻省理工学院,我们的一些团队正在开发突破性的

[VC] Visual Studio中读写权限冲突

前置场景: 编译没有报错,但是运行提示 内存异常: 情景1: 如下代码运行异常,提示引发了异常:写入权限冲突。*** 是 0xFFFFF..... char* str = (char*)malloc(10);str[0] = 0x30;  解决方案:要包含头文件<stdlib.h>  情景2: 在FileA文件调用FileB文件的函数,但是在FileA中却没有声明该B函数的原型

解决Visual C++ 中相互包含头文件的问题

在编MFC应用程序时,经常会遇到头文件相互包含的问题,很是苦恼,于是便求助于强大的CSDN,得到如下答案:   方法一:利用友元类   我一共有两个类,由于要在两个类的头文件里互相应用对方,所以,在每一个类的头文件里面现包含另一个类的头文件,然后在该类的定义中声明另一个类为友元类。如下:    #include "B.h"      class CA: public CDialog