VB/VBA的改进思考
1、最近的空闲里，在捣鼓VB，试图将藏在语法背后的高效性都还原出来，将VB隐藏的那些专业特性都释放出来，当然前提是不破坏VB的易用和安全特性。之前也点评过VB的两款重量级插件，试图针对他们的缺点，有所改进。
2、结果越来越发现，改进后的VB和Delphi越来越像，便在思考这种改进有没有意义，何不直接用Delphi？
3、即便不改进，VB/VBA都还是具有极高的使用价值的，这点在前面的文章中已经论述过。但是VB/VBA遭受专业人士的诟病，也并非没有道理。因为专业程序员，需要更细致的控制，需要灵活性，而恰恰是VB不愿意给的。在专业程序员眼里，VB里有太多不需要的，专为易用和安全性服务的指令，急需抛弃掉。这也是VB提升性能的根本途径。
4、且不说VB和Delphi的前景，这两玩意儿人家早就不买了，有什么好考虑的。即便考虑，也是别个出品方的前景，管用户啥事？用户需要了解的是，在可预见的将来，这货能否继续用于问题的解决。但看VB与Delphi之间的过往，VB的改进也必然会走Delphi这条路，抛弃掉非专业考虑，仅顾及专业人士。如果是这样，为何不直接用Delphi呢？
5、Delphi号称VBKiller，但并未干掉VB。有人说，VB有个多金的好爹。当然，这是一方面的原因。但另一方面，我想还是跟容错极强的易用性有关，这让VB抓住了更多用户(专业用户毕竟是少数)。VB对初学者的包容，是变态的。很多看上去非常扯蛋的，都能正确执行，这在Delphi中是万万不可想象的。既然如此，为何Delphi当年不迎合非IT呢？
易用和专业，就是鱼与熊掌，占一头就很难也占另一头。易用性，不同背景的人，所获理解也会不一样。比如C++++，对专业人士而言，很简单。但对于非专业人士，简直就是一道难以逾越的高山。所谓隔行如隔山，相信很多专业人士，在接触某个陌生专业领域时也会有两眼一抹黑点感觉。所以Python再简单，它也是给专业人士设计的。编程关键字就那么百十个，对于很多业余人士而言还是中文的香，道理都是一样的。
这里的易用性，不仅仅是上手快，容易理解，而是更少的挫败。这就不是你文档好坏能决定的了，这需要很多抽象层的封装。太过于封装，专业的细腻和灵活就没了，也就很难专业性了。相反，专业性，就是什么决定都由使用者决定，使用者智慧，则代码就精悍。所以，专业性，有个隐性的门槛在那里。
Delphi的定位就不是迎合小白的，所以他丢掉了BASIC/VB中很多认为不专业的东西，其中就包括在当时条件下被人诟病的解释机制，只保留了主流的编译机制。不迎合小白，除了商业对标需要差异化外，最主要的原因在于，Delphi没有强劲的后援会，生态力量太差，与微软硬刚，肉眼可见的死路一条。微软是需要拉拢非IT的，尤其在那个年代背景下，普通人选票才能成就系统霸权。所以，Delphi选择了一条错位竞争的路子，补上你VB的短板，做你短板的生意，其实也是一种无奈。
6、Delphi很难再降低门槛，或者继续降低门槛的工程代价过高。尤其是现在，有了更多的可选项。所以，尽管VB可以改进到Delphi的样子，即便不可能变成完全的Delphi，VB的适用边界的扩展，也足以不使用Delphi。
VB解释机制提供的实时编译，可以非常方便地进行源码调试。有人批评VB/VBA的IDE，不是缺这个就是缺那个，但是人家IDE有个重要的功能，人家还是调试器。或许有人说，VB/VBA的调试功能很渣。但能将调试器的使用门槛，降得跟VB/VBA的IDE一样低的，还有第二款么？其他调试器，一来就是反汇编码，你让花个几分钟学会录制宏的小白看？
所以，VB可以在群众中走来走去，又有Delphi的强大，为何不用？
[心]欢迎关注BtOfficer[心]（收藏、点赞、关注+转发）,更多精彩仍在继续哦（专栏文章将更系统，更全面），有严肃而枯燥的技术，也有轻松的唠嗑，更有现成工具等你来拿，期待你的加入！
1、最近的空闲里，在捣鼓VB，试图将藏在语法背后的高效性都还原出来，将VB隐藏的那些专业特性都释放出来，当然前提是不破坏VB的易用和安全特性。之前也点评过VB的两款重量级插件，试图针对他们的缺点，有所改进。
2、结果越来越发现，改进后的VB和Delphi越来越像，便在思考这种改进有没有意义，何不直接用Delphi？
3、即便不改进，VB/VBA都还是具有极高的使用价值的，这点在前面的文章中已经论述过。但是VB/VBA遭受专业人士的诟病，也并非没有道理。因为专业程序员，需要更细致的控制，需要灵活性，而恰恰是VB不愿意给的。在专业程序员眼里，VB里有太多不需要的，专为易用和安全性服务的指令，急需抛弃掉。这也是VB提升性能的根本途径。
4、且不说VB和Delphi的前景，这两玩意儿人家早就不买了，有什么好考虑的。即便考虑，也是别个出品方的前景，管用户啥事？用户需要了解的是，在可预见的将来，这货能否继续用于问题的解决。但看VB与Delphi之间的过往，VB的改进也必然会走Delphi这条路，抛弃掉非专业考虑，仅顾及专业人士。如果是这样，为何不直接用Delphi呢？
5、Delphi号称VBKiller，但并未干掉VB。有人说，VB有个多金的好爹。当然，这是一方面的原因。但另一方面，我想还是跟容错极强的易用性有关，这让VB抓住了更多用户(专业用户毕竟是少数)。VB对初学者的包容，是变态的。很多看上去非常扯蛋的，都能正确执行，这在Delphi中是万万不可想象的。既然如此，为何Delphi当年不迎合非IT呢？
易用和专业，就是鱼与熊掌，占一头就很难也占另一头。易用性，不同背景的人，所获理解也会不一样。比如C++++，对专业人士而言，很简单。但对于非专业人士，简直就是一道难以逾越的高山。所谓隔行如隔山，相信很多专业人士，在接触某个陌生专业领域时也会有两眼一抹黑点感觉。所以Python再简单，它也是给专业人士设计的。编程关键字就那么百十个，对于很多业余人士而言还是中文的香，道理都是一样的。
这里的易用性，不仅仅是上手快，容易理解，而是更少的挫败。这就不是你文档好坏能决定的了，这需要很多抽象层的封装。太过于封装，专业的细腻和灵活就没了，也就很难专业性了。相反，专业性，就是什么决定都由使用者决定，使用者智慧，则代码就精悍。所以，专业性，有个隐性的门槛在那里。
Delphi的定位就不是迎合小白的，所以他丢掉了BASIC/VB中很多认为不专业的东西，其中就包括在当时条件下被人诟病的解释机制，只保留了主流的编译机制。不迎合小白，除了商业对标需要差异化外，最主要的原因在于，Delphi没有强劲的后援会，生态力量太差，与微软硬刚，肉眼可见的死路一条。微软是需要拉拢非IT的，尤其在那个年代背景下，普通人选票才能成就系统霸权。所以，Delphi选择了一条错位竞争的路子，补上你VB的短板，做你短板的生意，其实也是一种无奈。
6、Delphi很难再降低门槛，或者继续降低门槛的工程代价过高。尤其是现在，有了更多的可选项。所以，尽管VB可以改进到Delphi的样子，即便不可能变成完全的Delphi，VB的适用边界的扩展，也足以不使用Delphi。
VB解释机制提供的实时编译，可以非常方便地进行源码调试。有人批评VB/VBA的IDE，不是缺这个就是缺那个，但是人家IDE有个重要的功能，人家还是调试器。或许有人说，VB/VBA的调试功能很渣。但能将调试器的使用门槛，降得跟VB/VBA的IDE一样低的，还有第二款么？其他调试器，一来就是反汇编码，你让花个几分钟学会录制宏的小白看？
所以，VB可以在群众中走来走去，又有Delphi的强大，为何不用？
[心]欢迎关注BtOfficer[心]（收藏、点赞、关注+转发）,更多精彩仍在继续哦（专栏文章将更系统，更全面），有严肃而枯燥的技术，也有轻松的唠嗑，更有现成工具等你来拿，期待你的加入！
请先 后发表评论～