如何看待「年轻人不要用 Visual Studio」的言论？
不都是说用了VS就不知道底层的东西云云。要是这么容易受到干扰，还算什么大牛啊。不用VS的唯一原因就是他不能很好地帮助你开发你的软件（譬如说你非要在linux下是吧所以VS就没办法了），而不是什么用了就会傻逼啊，用了就成不了大牛啊，用了你就学不会什么本科生都会的组成原理编译原理什么的。
2018更新：
VS也可以调试linux程序了！
他们是想让你学习vim还有emacs等工具，让你在无尽的配置文件学习中产生挫败感以换取自己的优越感。。。嗯，折叠我吧
我只想发个被折叠的答案，你们这些顶是什么心态 X= =X! - -#
这问题还是发CSDN吧，高仿点发stackoverflow，知乎上讨论技术问题，一点意义都没有，你说是不是，还充斥着一群不会因为不会用Eclipse/VS等工具的水军，瞎起哄。
嗯，真的大牛，常见的工具都能玩转，用什么工具跟牛不牛根本没关系，对于开发人员来说，能为PM快速解决问题，就是王道，谁管你用什么工具！！！你VS、MyEclipse用的好，编译选项你也会去手改的，根本没区别，那些说VS掩盖了编译过程的人，十有八九自己都没摸熟练VS的编译配置项。
存在即合理，爱用啥用啥，软件开发是自己学的，相信自己的选择就好，别随便听信别人说的，如人饮水，冷暖自知，本来就这样。
---------------------------------------------------------
其实这个时代还有个神器 sublime text
jetbrains也出了好多神器，比如webstorm我觉得劝戒年轻人（或者我们视为初学者）不要用VS的程序员可能持有这些心态，我把它分为正面劝戒和负面劝诫：
正面：
- 希望你能够通过 makefile, premake, grunt, gulp 等 build 工具，一步一步地搭建工程环境从而对程序如何从繁多的文件中，build生成一份用户可用的模块或执行文件 有一个详细全面的认知。理解整个项目的生成原理，可以让你更好地和其他的程序员一起工作，更好地命名你的原程序文件以及规划你的文件所在路径。而且对于拿到手的项目，可以理解他在编译的每个时间段都做了什么事情。毕竟现在大型项目的build过程，不单单包括调用编译器，他或许还涉及到对源代码拷贝，连接合并，或者对源代码模板解析生成中间文件等管线操作。
- 希望你多开阔眼界，看看程序世界中各种各样的工具的处理方案，也许能够从其他的工具中获得一些好的灵感，或者通过不同种类工具的学习来融会贯通。
- 希望你不被VS而约束或绑死在一个操作系统平台上做开发。而通过对通用工具的熟悉，获得良好的开发素质，从而在未来的技术变化中更快更好地适应不同平台。
负面：
- 觉得自己不用VS很牛，希望用这种方式迅速占领高地，提升B格，拉开你与他的差距。
- 希望你绕更多的弯路和花更多的时间去研究一些有的没的，从而平衡自己多年使用其他工具获得的技能的心态。
- 希望你能够和他使用相同的工具来获得简单交流的快感，以及拉帮结派。
无论怎样，强制要求你不用或者强制要求你使用特定工具的low b，请无视他的存在。
而那些在你使用过程中，跟你介绍其他工具如何处理这些问题，以及告诉你项目如何完整构建，抛开VS该如何来做，以及给予你很好的其他平台解题思路的程序员，请好好地请他吃饭，他们是真心想帮助你提升你的视野和编程水平，并且真心希望你能够加入到他们团队中形成良好交流的人们。参见知乎前段时间关于为什么家长反对学校里装空调的答案。
核心思想是：我当年没有，你也不许有。知乎上的问题经常会引起吵架的原因，在于问的问题非常模糊，回答的人又不愿意多花点时间去把问题理一理。这个问题关键要搞清楚“年轻人”和“不要用VS”的概念。如果年轻人是指刚参加工作不久的IT从业人员，不要用VS指的是完全不要去用VS这个工具，那当然有问题啦，一旦开始做实际工作，肯定是要用效率最高的工具，立刻解决工作中遇到的问题。也就是说什么好用，什么快就用什么。
假如“年轻人”指的是大一的计算机系学生或者更年轻的，高中、初中的爱好者，不要用VS指的是不要局限在Windows+PC的平台上，那么这个说法就没有什么问题啊。
初学者，又有大把的时间，当然要把各种各样的东西都尝试一遍，LFS都不够，最好能从单片机入手，先写一个只有一个无限循环的，让某颗灯闪烁的程序，到慢慢增加复杂度，写出能接收3x4键盘输入的程序，再增加复杂程度，做出一个简单的协作式的多任务的程序，再到做出一个用时钟中断的真正的多任务的程序。再意识到如果程序再复杂，我就需要一个操作系统。再去研究现有的操作系统是如何实现的。这样一步一步，从低级到高级，都有了一些了解，再选择自己感兴趣的领域去深耕。
想不出这样对于有大把时间去范错误的年轻人有什么不好？非要一开始就去学习拖拉控件？
几十年之后，咱们回过头再看现在的编译工具链，就像咱们现在去看打孔纸带一样。
在纸带上打孔就是锻炼基础？？啊呸！
我从来不劝诫别人不要用VS，我只是劝诫别人不要再用VC6.0当然，对于初学者我会建议他们装CODEBLOCKS等轻量级的IDE……这样比折腾VS省事儿多了。因为那是个java程序员
因为那是个unix，bsd，linux，android，ios， ...... 程序员
因为那是个做网页的
因为那是个画图标的
......
因为那个人不开发.net
不用VS的理由可以列出一百个，最后一个有共通性。
以我的经验来看，推荐新手从C/C++和VIM+GCC入手的基本都是坑人。新手不应该浪费时间在这些细枝末节上，要么用VS，要么用其他比较轻量化的IDE。新手不应该在任何细枝末节上浪费时间。
我从VS入门学的C++，现在在Linux下写东西也一点都不费事。
教育领域伪科学重灾区，民科多。
正规的科学的教学方案，第一件事就是制订教学目标/学习目标。如果连教学目标/学习目标都不清楚，后面的教学计划/学习计划，基本上就是一团糟。
计算机编程的教学范畴/学习范畴非常大：计算机编程语言语法、计算机编程环境、计算机编程模式和思想，......。
由易到难，从简单到复杂，循序渐近，这是学习的基本规律。
违背这种规律者，轻则事倍功半，重则从入门到放弃。
在制订教学计划或者学习计划时，一定要注意：确定学习目标的层次和范围。
Visual Studio等集成开发环境，可以使得初学者集中精力于计算机语言的语法、算法上，而不必纠结于其它较复杂较难的知识，降低学习门槛。
我觉得这跟和尚劝人戒色一个性质: 看不得别人爽纵欲当然伤身，然而大部分成年人都能掌握好度。你一个和尚愿意天天拿vim练童子功，我们也不歧视你，但你天天在别人耳边念叨，红粉即骷髅，ide都是邪道，那就怪不得别人踹你了对于说『建议学生一开始不要太借助IDE，多用gnu tool chain + vim』的人
我一般会回『你的建议很好，我建议你一开始不要太借助toolchain和vim，需要什么就自己实现什么，记得做好跨平台，对了记得给编译器做个GUI』
另外，做人要有底线。交流辩论可以，撕逼喷人还是算了。
这个叫有人的人不行，我一般都是劝学编程的孩子不要用电脑。自己造一个啊，这样才可以充分理解底层原理嘛。
2018.4.18更新：现在非常希望VS有生之年官方出开发单片机的功能把keil给代替了（滑稽）2018.2.10更新：
我就搞不懂为啥你们一群人开始以“因为VS安装起来大，安装起来麻烦，所以不用VS”开始答题，还给出一堆截图，醉了...（真是因为VS大，所以VS不好不用系列）
以下为原答案：
对于初学者有IDE为何不用呢，让一个控制台的基础命令都不会的新手配置几个小时乱七八糟的东西最后发现跑不起来helloworld的挫败感比起VS建立默认工程写上两行代码点一下绿三角调试看到控制台输出helloworld来的成就感真的是差远了。
他们的抽象层次是不同的，好比你学c语言并不需要先学大学物理数字电路等等课程（夸张）。
等熟悉了编程语言以后有些人自然会对更多的细节感兴趣，这时候再去学习用gcc+vim等奇奇怪怪的方法来写代码会更加有趣。
（瞎写一堆 轻喷= =）
因为他们：
- 混淆了困难和厉害
- 忘记了程序的最终目的
我来晚了，好在很多回答都只是进行了调侃，所以给我留下了深入挖掘这个问题的机会。
其实这是一个普遍现象，而我们很多人可能只是“五十步笑百步”而已。
假设两个程序员，开发同一个项目：
- 一个只能用Visual Studio才能开发，离了智能提示寸步难行；
- 另外一个就凭一个记事本，唰唰唰的就把程序跑得飞起。
你觉得哪一个更厉害？
虽然我已经亮明了观点，但我估计还是有很多同学会说“还是第2个厉害点吧？”如果这样的话，你有必要继续看下去，否则的话，可以直接点赞离开了，O(∩_∩)O~
我的答案是：其实不知道谁更厉害，或者两个都一样厉害。
你可能不服气，“哪里哟！用记事本，没有智能提示，不能断点调试，需要自己编译……厉害多了好吧？”
确实，省略号之前你都没有说错，但是，注意这个但是，接下来正确的推论应该是：（用记事本编程）要难多了吧？
“要难很多”，和“要厉害多了”，是两个概念 —— 两个非常容易被混淆的概念。
“很难的一件事情，我都能把它搞定，难道我不是很厉害吗？”你或者会这样问。
但事实上，更准确的问法，应该是：
“同一件事情，我能用一种更困难的方法把他完成，难道我不是更厉害吗？”
这当然就不一定了。
关键在于你的目标是什么？
比如登山，张三沿着小路蜿蜒而上，李四从悬崖峭壁上攀岩而至，王五坐着缆车悠哉乐哉的就到了，谁更厉害？
- 如果目标就是“到达山顶”，大家一样的厉害，因为大家都到达了山顶；
- 如果目标是“用最短的路径到达山顶”，那李四最厉害，攀岩嘛，基本就是条直线；
- 如果目标是“最快最轻松的到达山顶”，那就是王五最厉害了，缆车最快，“嗖”的一下就上去了。
- 如果目标是“安全又省钱的到达山顶”，那就是张三最厉害……
明白了吧？
然而，我们很多程序员的目标是：哪种方式最“酷”最“难”，哪种方式“会的人最少”……所以无论如何都是李四最厉害！
你自己好好清醒一下，我说的是不是就是你！？
说中了你的小心事吧？说中了就赶紧的点个赞，麻溜的！然后我们继续。
这就是为什么“有宇宙最强IDE不用，要用记事本”的最深层次的心理动因，什么记牢语法、熟悉编译原理，吧啦吧啦，都是借口。以此类推，还有很多类似的观点：
- 看不懂的书（代码）才是好书（代码）
- 会算法会数据结构懂底层懂计算机原理懂离散数学懂……的程序员才是好程序员，哦，不，不懂这些都不能算是程序员，只能是码农、码畜
- ……
说回开发，很多同学肯定又不同意了，呵呵。
算了，懒得写了。一提这事，有些人就像被踩了尾巴一样“吱”的一声就要跳起来——我都已经拉黑了好多人了。是的，飞哥就这暴脾气，出言不逊的，立马举报拉黑，?(￣??)?
就这样吧，懂的人，应该就已经懂了，不懂的人，随他去吧。毕竟人生就是这样折腾来折腾去的，攀岩也有攀岩的风景和美丽；而且要是都来坐缆车，也忒挤了点。
++++++++++++++++
新人愿意更深入了解的：编程那些事：菜鸟入门·一起帮
收藏进：野生程序员，欢迎关注。
记得当年江湖有两大门派，一个号称“真正的程序员用C++（MFC）”，另一个则称“聪明的程序员用Delphi”，当时两大门派吵得不可开交。现在呢？两个门派都没落了。
昨天看到微信张小龙的一句话：“我们不谈情怀只判断对错”。嗯，那些劝诫他人不要用VS、不要用这个那个的，都是空谈情怀的人。
我见过太多的人抱有类似的心理：自己趟过的雷区，如果别人绕开了，并且直接通过新的通道直接追上了自己，会心里很不开心，总是喋喋不休的给他说，”你少经历了很多风景对你成长很不利“，”你没趟过某某雷，以后遇到某些事情肯定会不知道该怎么处理“。绝不是对号入座，但是真的见到非常多类似的人和事，也绝对不限于软件开发。
其实你说vs帮程序员做了啥嘛？
- 图形化封装了软件项目管理。提供了一个虚拟目录结构来管理源码。
- 自动生成了(纳入项目管理的)源码文件之间的依赖关系，和源码文件与目标文件之间的依赖关系，默认帮你生成了目标文件的命名规则，供于编译。
- 图形化的帮你提供选项配置管理（包括编译，链接等等操作的选项），平台管理。
- 提供一些高级的Hook, 比如编译前的预处理，编译后的后处理。QT生成的VC项目会自动MOC预处理，就是使用了这样一套功能。
- 给点语法提示，这算是IDE的添头吧；集成化一些流程，例如源码管理，单元测试，profile，这是企业化思维的结果：一站式处理，避免注意力分散化带来的工作效率降低。
1，2，3，4 其实都是属于非常琐碎，但是很容易做的粗糙，实际其实又很重要的软件管理和维护上的活。说实在的，大家都是写代码的人，如果能有一个工具能帮我们封装简化上面这些和实际开发工作关系不大的流程，简直是举手欢迎，唯一的缺陷是这工具不能跨平台（或者说不能导出跨平台的makefile...），qmake&cmake可以视为此类前端来封装这些工具来实现间接跨平台。
有的工作其实本来就该语言编译工具负责的。例如用一个编译选项，去集成编译依赖判定和编译 这2个操作。只是因为现实有些缺位。。。非得用makefile，以至于网络有人说出了：”...不会手写makefile 就绝对没写过10万行以上大项目“这种话。
写的东西有些没有逻辑化，只是简单的罗列了一些我思考的结果。
具有讽刺意味的是，在写C/C++的时候，圈子的主流想法是“告诫新手不要使用自动化工具，而是要手工去理解整个过程”，等到写JavaScript前端/后端的时候，这帮人又争先恐后地去用
- npm等包管理器
- Yeoman等脚手架工具
- Gulp、Grunt等构建工具
- WebPack等打包工具
- 等等等等
好像会用这些新潮工具又成了高智商的体现一样
为啥点了不感兴趣还是会出来…反正早晚要用
而且vs安装配置真的方便，下载，安装就没了
而且这点大小还没个游戏大，随便按个啥3A游戏都比这个大
你让一个小白去配环境变量么
或者让一个命令行里啥时候该有空格都不知道的去跑个gcc么
要花十分钟告诉他-o和-O的区别还是说"点呢个绿色箭头就行"
或者给他传demo的时候说"你先打开命令行，切到xxx目录，对对对打个make，啥他提示找不到命令？"还是"你双击呢个.vcproj"
ide就是为了方便人存在的，想要学编译原理人家自然会去学，我就是想做窗口咋滴了，不知道编译的方式还能妨碍我美术小天才不是
不要用 VC 6.0。
不要用 VC 6.0。
不要用 VC 6.0。
老师们请放过学生，要用 VC 教 C++ 请用最新版。理想地也可以教一下 gcc/clang。
