看到这篇文章非常有感触，因为原po的心境与疑问我曾经走过， 虽然我的程式资历还并不算深，我想我可以试着回答这个问题。 我是念土木系的，大学必修的计算机程式也是教c++，我还被当过一次， 九年前当掉我的老师，现在成了我博士班的老板， 但我心底非常感激他当初当了我，才让我发现写程式是多麽好玩的一件事。 总之，大学时代重修c++的那时候，虽然我已经能认同写程式是很有趣的事， 但是在我眼里，我所学的东西实在太有限了，对土木系而言，为什麽需要计算机程式？ 因为我们常常在碰到矩阵，可是至少在我们这个时代，已经渐渐不需要「写程式」了， 因为excel实在已经可以处理掉我们大学部会用到的所有难题。 而後来升上硕士班，我其实在硕士班念的组别还在土木所下， 只是和资讯没有这麽高度相关，可是因为因缘际会，在硕士班的时候， 我因为两个原因决定要学VB： 一个是我在excel里用到了VBA，另一个是我用VBscript来写asp， 我觉得VB不但好学易用又无所不包，小小的投资、大大的获益， 当时我回顾自己初学c++的过程，心底也冒出一个很大的问号：Why C++？ 当时我受到VB的震撼也许就和原po一样，我觉得它不但能轻易作出漂亮的GUI， 而且正因为VB是比尔盖兹的亲生孩子，所以它在微软帝国的平台下可说畅行无阻， 其实我那时最欣赏的是excel+VBA， 因为你的使用者介面和资料储存媒介完全就放在一个令你熟悉不已的环境当中。 在c++里，你要会fstream来做档案I/O，而就算不做视窗操作介面， 也至少要有个while loop配合switch case之类做个操作选单，有点麻烦。 後来硕士班毕业到重返校园的这段期间，我开始接触物件导向程式设计， 却开始有了全新的视野，也直接正视到了VB6.0一个最重要的问题： 它的物件导向支援能力是有缺陷的。也许有人会说，那VB.Net不就解决这个问题了吗？ 但广义来说，.net「本身」算是一种全新的语言， 只是它允许你用自己所熟悉的语法去操控它， 换言之我并不认为VB是「进化」到.Net平台而且因此拥有了完整的物件导向能力， 相反的讲，它应该是被「并吞」了，也或许因此才被赋与了完整的物件导向功能。 （讲得好听一点或可说是「融合」，因为严格来讲它们都是微软帝国的子嗣嘛。 但我认为一个语言的特色与核心价值就在於它拥有「别的语言无法轻易做到的功能」， 进到.net平台之後，因为函式库与容器类别共用的原因，这样的事几乎已经不存在， 任何一个VB.Net可以轻易作到的事， 用C#或CLI/C++一定也能在「相同的辛苦程度」下完成。 然而，这也是为何我深深认为.net并不像是一个平台， 而是一种「可以穿上个种语法外衣的独立语言」， 因为乍看之下你会误以为它对所有程式语言取了「联集」， 事实上它当然没有如此强大，它取的只是「交集」。 举C++的例子是最明显的，.net有一套类似STL的容器类别与演算法， 而且它鼓励（或曰强迫？）你使用这一套， 如果你曾和我一样试着帮旧的c++ code穿上.net的外衣，就会知道它有多麽排外， 不如把整份code全部重写。） 而我认为原po的问题可能就在， 初阶的计算机程式课程多半着重流程控制等基础概念， 但这些基本功能绝对是任何一个程式语言都能办到的事， 它还无法看到程式的个别特色和专长，但vb在这方面显得相当讨好初阶使用者， 诸如「作出漂亮的GUI」这件事本身，我和原po有完全相同的迷思， 我刚开始学程式设计时，很不能忍受为何要写那种dos时代的console主控台介面， 更好奇「为什麽市面上被公认的c++好书从不教人做漂亮的GUI」， 我後来终於想通这个问题是因为在外头的课终於接触了OOP和MFC， 我的心得是：MFC是用来理解OOP的一个实例， 但说实在它对程式设计的启发性过低，使用上又太麻烦， 我认为「翻着一本厚重的手册，找出你要的函式及应该传入的参数」对一个程式员来讲， 只是一种应该承担的必要之恶，而且随着时代演进， 会一直有人企图找出「减轻这种必要之恶」的方法，可是相对来讲， 程式设计的基本精神，流程控制的原则，design pattern这些东西， 却是会长长久久，会成为你「永恒的资产」，而不需随着时代过去而频繁更新的。 那麽回到主题，既然只是要学基本精神，为何要选c++？ 因为它的可能性最广。当你初学程式语言， 你很难想像未来的你会在资讯世界的哪一块，到底接近机器还是接近人， 是低阶的、写driver、操作记忆体做自控呢？还是高阶的，当MIS，用oop写应用程式呢？ 可是C++让你走向两边都成为可能。 就低阶来讲，它可以使用指标操作记忆体（虽然这基本上是危险动作，不被鼓励）， 就高阶来讲，它拥有既完整又强悍的物件导向功能。 再讲到更重要的「政治意义」， 其实我心底觉得这才是你选用何种程式语言做为开发工具的重点。 当你已经掌握了程式设计的基本概念，要换一种语法是轻而易举， 可是你一定也要因此投入心力与成本。 除了语言本身的特色（高阶与低阶，或某方面的特长）之外， 我认为语言的可用性与便利性，所比较的就是在它背後的函式库及类别库， 谁的内建函式库又大又方便，往往就能博得程式员的欢心， 比方说我一开始为vb所惊艳，因为它的字串不但是内建的变数型别， 而且字串处理函式又多又强大，可是我错了，因为当时我不知道C++的字串型别， 只要透过.c_str()就能转成c-style的字元阵列字串，然後喂给c的字串处理函式解决。 而c++大部份「较复杂」的字串处理函式（像split）都放在c的函式库里面。 然後我又觉得vb的array要做redim改变大小， 实在比c++的malloc动态记忆体配置要方便太多，这点我错得更离谱， 因为当时我还没学STL，如果会用vetor容器，它又比vb的redim要方便太多。 我的两点亲身经历就说明了，使用者往往无法在短期内了解一个程式语言的好， 是因为他不知道这个东西被放在内建函式库的哪里，甚至能不能轻易被做到。 可是函式库或者类别库就牵涉到我所定义的「政治」， 它是别人包好的东西，当然就操在别人手里。 第一个要看「统不统一」；c++的compiler有很多厂家、很多平台在做， 如果你惯用的函式只要换了一个开发环境就不再有效，或要改变语法， 那它不值得牢记在心，或者说它让一个语言分裂，不如再多学其他语言算了。 其实领悟了这个概念後，我终於知道了为什麽知名的c++好书从不教人做漂亮的GUI， 因为GUI正是C++当中从来不统一的部份。 第二个要看「恒不恒久」：语言可能进化，当然也有可能消灭， 当然一个程式语言要完全在地球上消失并不容易，或说它的生命周期一般而言都很长。 先讲「进化」，进化是正面用词，代表功能更强大， 但进化当然有困扰，因为你要更新，假设它不向下相容的话。 所以一个常常在进化的程式语言未必不是好的，但至少代表它还不成熟， 才需要改版得这麽频繁。而进化亦有文明和野蛮之别， C++的进化是有一群庞大严谨的委员会制定的，而且多半会顾念向下相容， 以新增代替修改。可是VB是微软帝国的，基本上它说了算， 君不见如此多人为XP请命，微软仍想强硬终结其生命，以遂Vista推广吗？ 就如.net其实也是个非常好的平台，但它毕竟改得有点快， 从1.0到3.0，已经有蛮多东西都长得不太一样了，想精通它， 可能等它先成熟或者自己的工作（研究）需要先碰上会更好。 再讲「消灭」，其实是同一问题，世间少有恒长，VB确实是比尔盖兹的「爱子」， 而且比尔盖兹最初的心愿曾是：「没有VB做不到的事」， 可是微软帝国会存续（也许），盖兹却会先衰，如今C#做得如此之好， 我认为VB就算没被放弃，至少可能已经开始面临失宠危机。 当初它的优势何在呢？简单、直觉、好用；而其实这些优势已被采纳到.net平台之上， 而且可能有过之而无不及，在这情况下，VB的优势已被.net粹取而去， 但它本身却只能算是.net的一个子集，其实，如果就我个人的看法来讲， 这语法还能做很多事，所以仍有很大的价值， 但也因为不只它能够做到，所以这价值已经没有从前那麽大了。 话再说回来，我回到校园再作博士班的进修，还是念土木所， 只是念与资讯高相关的电脑辅助工程组，因此程式开始变成了我的本行， 但是回顾我一路以来断断续续接触程式的过程，曾经有过的这些心境，都还历历在目， 其实我现在从不会比较程式的优劣，世上没有最强的程式，只有最强的设计师， 那就像世上没有最强的武术，只有最强的武者一般。 虽然，我们可以就「普及率」、「易学度」、「可携性」之类的指标， 来评估哪种程式语言最适合做为自己的「母语」，但如果要就此比较优劣， 那就像孔子比关公，文圣武圣要如何分出高下之别呢？ 一点浅见，给各位大大见笑了，望能抛砖引玉，造福各位板友… -- 我 是　可　悲　的　废　柴　作　家 http://bloodaugust22.spaces.live.com --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 123.193.41.88