#深圳头条# 国内程序员的创新实验，凹语言是披着 Go 和 Rust 语法外衣的 C++ 语言：
1.凹语言™源码文件后缀为 .wa；
2，凹语言™编译器兼容 WaGo 语法。WaGo 是 Go 真子集。使用 WaGo 语法的源码文件后缀为 .wa.go。凹语法与 WaGo 语法在 AST 层面一致；
3.凹语言™支持中文/英文双语关键字，即任一关键字均有中文及英文版，二者在语法层面等价
看看目前的高房价，以及所谓的二手房指导价政策，就知道linux内核是多么睿智的一个决策者。
linux内核的内存管理遵循一个很朴素的哲学，那就是：平衡，英文名balance。
“最大程度的给你用，也保证后来者可用，在这两者之间保持一个平衡。”
因公平而平衡，因平衡而公平。
翻翻kswapd的源码，balanc这样的词汇随处可见，balance_pgdat()，zone_balanced() 等等。
linux内存管理的张性很大，他会分配尽量多的内存给系统中已存在的各个执行体以提升系统整体性能，让你的linux系统看起来内存占有率很高，如果是一个新手，你肯定以为系统内存都不够用了；
然而它又能保证在新的执行体运行起来的时候给他足够的内存使用。
既能照顾先行者的利益，又能考虑到后来者的需求，就靠两个字：平衡。
想想这二十多年来，先行者攒了一套一套的房子，而新生代的年轻人只能咬着牙去接手高价位的房子，看着是市场行为，其实是平衡的天平转向既得利益者罢了。
大家都应该跟我学学linux内核开发。
#Linux# #linux# #C语言# #运维# #IT# #嵌入式# #单片机# #我要上头条# #我要上微头条# #Java# #代码# #程序# #程序员# #程序员那些事#
#Python应该被丢进垃圾桶#
网络上铺天盖地的宣传Python，一开始没有搞清楚这是什么，原来又是美国低价推销自己的标准，这个编程语言再好，再怎么免费咱们也不能用，因为用怕了，因为华为！！！
自Python正式推出后，范罗苏姆一直领导Python社区，并被称为“仁慈的独裁者”（Benevolent Dictator For Life）。
如今Python成为最受欢迎的编程语言之一，因为其简单易学、代码短等特点成为人工智能的首选语言，可以预见Python语言很有可能是未来最具有发展前景的编程语言。
打破美国的企图：建议转研发单位，计算机二进制语言不变，研制一款万用编译器，各国可用其语言对号入座即可。我们只要把现实中文语法用字进行改造形成一套计算机体系语言就行，不断改进发布，统一源代码表达式。打破英文统治高科技人人学英文这一霸权，让Python成为垃圾桶！
华为要推仓颉编程语言了，中文关键字怎么定？说说就好，为啥一定要用中文编程？中文自身的编码不还是洋人弄的十六进制，中国自研的CPU不也还是采用洋人的架构、洋人的技术、洋人的理论？
小孩子编程是可以为中文，也可以方便看懂源代码，但现状是针对图形化编程，一旦到了源代码立马脑袋大。这样搞法，其实又会是另外一个易语言。只是关键词尽量简洁，减少代码容量，其他的用现代白话文也没意义。
如果连这点英文都搞不定的人，还是趁早别学编程了，不然写出来的东西都不靠谱。编程和小孩子涂鸦不一样，即使是小孩涂鸦，也不过是娱乐。
为什么要看源码#
我们在做项目的时候一般会遇到下面的问题：
（1）不知道如何去设计。比如刚入职场时，来一个需求需做概要设计，不知如何下手，不得不去看当前系统类似需求是如何设计的，然后仿照去设计。
（2）设计的时候，考虑问题不周全。相比职场新手，这类人对一个需求依靠自己的经验已经能够拿出一个概要设计，但是设计中经常会遗漏一些异常细节，比如使用多线程有界队列执行任务，遇到机器宕机了，如果队列里面的任务不存盘的话，那么机器下次启动的时候这些任务就丢失了。
对于这些问题，说到底主要还是因为经验不够，而经验主要从项目实践中积累，所以招聘单位一般都会限定工作时间大于3年，因为这些人的项目经验相对较丰富，在项目中遇到的场景相对较多。工作经验的积累来自于年限与实践，然而看源码可以扩展我们的思路，这是变相增加我们经验的不错方法。虽然不能在短时间内通过时间积累经验，但是可以通过学习开源框架、开源项目来获取经验。
另外，进职场后一般都要先熟悉现有系统，如果有文档还好，没文档的话就得自己去翻代码研究。如果之前对阅读源码有经验，那么在研究新系统的代码逻辑时就不会那么费劲了。
还有一点就是，当你使用框架或者工具做开发时，如果你对它的实现有所了
解，就能最大化地减少出故障的可能。比如并发队列ArrayBlockingQueue里面关于元素入队有个offer方法和put方法，虽然某个时间点你知道使用offer方法时，当队列满了就会丢弃要入队的元素，之后offer方法会返回false，而不会阻塞当前线程；而使用put方法时，当队列满了，则会挂起当前线程，直到队列有空闲，元素入队成功后才返回。但是人是善忘的，一段时间不使用，就会忘记它们的区别，当你再去使用时，需进入offer和put方法的内部，看它们的源码实现。进入offer方法一看，哦，原来队列满后直接返回了false；进入put方法一看，哦，原来队列满后，直接使用条件变量的await方法挂起了当前线程。知道了它们的区别，你就可以根据自己的需求来选择了。
看源码最大的好处是可以开阔思维，提升架构设计能力。有些东西仅靠书本和自己思考是很难学到的，必须通过看源码，看别人如何设计，然后思考为何这样设计才能领悟到。能力的提高不在于你写了多少代码，做了多少项目，而在于给你一个业务场景时，你是否能拿出几种靠谱的解决方案，并且说出各自的优缺点。而如何才能拿出来，一来靠经验，二来靠归纳总结，而看源码可以快速增加你的经验。
如何看源码#
那么如何阅读源码呢？在你看某一个框架的源码前，先去Google查找这个开源框架的官方介绍，通过资料了解该框架有几个模块，各个模块是做什么的，之间有什么联系，每个模块都有哪些核心类，在阅读源码时可以着重看这些类。
然后对哪个模块感兴趣就去写个小demo，先了解一下这个模块的具体作用，然后再debug进入看具体实现。在debug的过程中，第一遍是走马观花，简略看一下调用逻辑，都用了哪些类；第二遍需有重点的debug，看看这些类担任了架构图里的哪些功能，使用了哪些设计模式。如果第二遍有感觉了，便大致知道了整体代码的功能实现，但是对整体代码结构还不是很清晰，毕竟代码里面多个类来回调用，很容易遗忘当前断点的来处；那么你可以进行第三遍debug，这时候你最
好把主要类的调用时序图以及类图结构画出来，等画好后，再对着时序图分析调用流程，就可以清楚地知道类之间的调用关系，而通过类图可以知道类的功能以及它们相互之间的依赖关系。
另外，开源框架里面每个功能类或者方法一般都有注释，这些注释是一手资料，比如JUC包里的一些并发组件的注释，就已经说明了它们的设计原理和使用场景。
在阅读源码时，最好画出时序图和类图，因为人总是善忘的。如果隔一段时间你再去看之前看过的源码，虽然有些印象，但当你想去看某个模块的逻辑时，又需根据demo再从头debug了。而如果有了这俩图，就可以从这俩图里面直接找，
并且看一眼时序图就知道整个模块的脉络了。
此外，查框架使用说明最好去官网查（这些信息是源头，是没有经过别人翻译的），虽然是英文，但是看久了就好了，毕竟还有Google翻译呐！
当然研究代码时不一定非要debug三遍，其实这里说的是三种掌握程度，如果你debug一遍就能掌握，那自然更好啦。
在项目实践中经常会遇到一个场景，就是需要等待某几件事情完成后才能继续往下执行，比如多个线程加载资源，需要等待多个线程全部加载完毕再汇总处理。
点评下插件CodeSMART for VB6，给大家做个参考吧
1、收费且贵。每台机器的注册费用为249美元，折合人民币大概1762元，比好多共享类软件都贵。在国内，经历过盗版软件的野蛮生长，这么贵的价格，即便是版权意识逐步觉醒的今天，估计也很难有市场，更何况此软件是一个插件，解决的问题也并不怎么痛。
2、只有英文版。国内VB用户，绝大部分都是半路出家的业余人士，英语仍然是一个不小的门槛。哪怕VB中文版中，少数几个英文关键字，都被吐槽不断，更别提这个插件是全英文的了。
3、只适用于VB5/VB6，不适用于VBA。VB只有32位IDE，而VBA有64位IDE。后者会伴随Office得到系统级支持，而前者已经明确不会得到支持。所以，VBA会最终成为VB家族最后的继承者，在办公自动化的全民应用开发中，将扮演最后的大多数。由于VBA在某些方面，比如IDE对象接口，进行了针对性精简，这就导致VB6适用的插件，不一定适用VBA。
大家都知道这类插件都是DLL方式实现的，会加载到IDE所在进程中。对于VBA而言，自然就会涉及32与64位兼容的问题。这里面会涉及到更底层（系统级）的知识，会的人一般都是专业程序员，而且很少会涉猎VB/VBA的应用场景。
原本VBA可以自己制作这类插件（DLL），但同样受限于商业定位的原因，VBA不太可能很封闭，所以这类插件更多以开放的姿态出现。这不免让很多VBA的使用者感到失望，这大概也是该插件未能涉足的原因吧。
4、功能太过花哨，未抓住核心痛点，能发挥的价值有限。VB/VBA的IDE对于写代码，功能是足够的，语法高亮，语法智能提示，代码补全，缩进控制等，该有的基本都有。但相较于现代IDE，可能体验上还差了点意思。
比如，代码窗口居然不支持鼠标滚动，代码没法折叠，代码补全太渣等。但这些其实并不让人感觉很痛，毕竟窗口拖放控件的主场景下（面向过程），双击界面，就可以定位代码块。工程资源管理器，也很方便切换模块。VB/VBA工程规模，一般也很难达到专业管理的层面。
VB/VBA源码编辑的真正痛点在于，如何扩展源码的书写（语法扩展），能够借助编译器编译出更精简的指令。如何能够像C那样嵌入汇编，让各个层面的手段都能使上。如何将VB/VBA变成Windows资源的胶水。如何在解释和编译机制下，让语法扩展，获得相同的结果。如何进行专业级调试等...。然而，这款插件仍然仅在UI表面上做文章，给人不痛不痒的感觉。
比如，将核心功能集成在单独的窗格中（工程管理、设计管理、文库管理等），虽然该窗格集成在了IDE中，也可以代替原工程资源管理器窗口，但是未能充分利用原有功能和空间位置，不仅增加了IDE资源开销，而且压迫了工作空间。
再如，窗口标签栏，看上去增加了便捷性，但当窗口多的时候，就会让界面看起来很零碎。代码窗口中的视觉增强（实时绘制），并无多大作用，却可以增加编码时，IDE的负担和崩溃的机率。代码补全，看上去不错，但未能解决VB/VBA编码中真正的重复，比如API的Declare，常数、结构的声明等。更别提，编译器层面附赠的公式化指令。
总之，该插件花哨的成分，大于实用的成分，没能抓住VB/VBA的核心痛点。读者朋友们，你们有什么看法呢？欢迎评论区讨论哦。
欢迎关注BtOfficer（收藏、点赞、关注+转发） ,更多精彩仍在继续哦（专栏文章将更系统，更全面，但需要阁下支持哦），有严肃的技术，也有轻松的唠嗑，期待你的加入！
