g++ 哪有包的概念。强行要包也得 pkg-config 好吧。
这种情况不是先 -v 自己看搜索路径么。

@shintendo 实际上现在要求可编程的 Markdown 项目还是不少的，就是门槛不那么高罢了。不过由于一般用个 mdbook 什么的就能上，倒是使 LZ 说的这类不允许或者不方便自己部署的平台更加显得鸡肋而业余。

对比看，门槛高点的，比如 TeX 或者 Scribble （ https://docs.racket-lang.org/scribble/）之类的 DSL，跟传统意义上的编程明显更接近（或者根本上就是）。Markdown 的可编程性弱体现在没法通过自身可移植地直接扩展，要折腾实现罢了，但这方面也可以算得上是另一种意义上的门槛高。

看起来只是能管理内容，还管理不到资源所有权也定制不了流程……告辞。
SaaSS considered harmful.

@Torpedo 看你管啥叫稳定。
因为 Win32k.sys 的关系，Windows 的原生 GUI 组件在内核层面上就不可能保证排除不确定的稳定风险，有的还是可利用的安全漏洞——从 WinXP 到最近的 Win10 都有。
反过来，其它用户空间实现的方案可用性各有不同，但基本上只要内核相关路径上没明显的 bug，就没啥机会不稳定到整个系统挂掉，而至少能保证有机会让你能看到 GUI 意义上的“内部错误”。
当然，间接的问题像驱动之类要出事都跑不掉，不过系统厂商可以把这个锅甩掉……

@passerbytiny 文本界面就是基本的 UI，而且对程序员来讲通常还比其它种类的 UI 更重要；而这里残废的顺序刚好和 GUI 的可用性反过来。

不一定，看不懂是一个问题，也有小部分可能是因为说得太详细了，又没什么值得提的错误，反而没什么好吐槽的了。

@liprais 小白文说到底是按读者反映评价的。专业圈子门槛高点，但灌水的比例未必少，专门到已出版的论文集里找文献都照样可能有大部分都是小白文的情况，更别说满世界找的预印本啥的了。

因为非得说人话把问题跟不知道上下文的围观群众说清楚，是得强迫过一遍不管自己有没有拎清楚的部分的，这时候使用的思路和原来不一定相同。所以有时候用旧的思路潜意识没想清楚就略过和漏掉的东西会重新浮出来，这很正常。

微信的问题是要么干脆不用，否则 Windows 日常也没法代替移动端，因为那个烧饼登录逻辑和功能残废的问题……（ Windows 设备要抱起来扫码就算了 8，，，）
更扯的是要想要数据容易备份归档，光移动设备也不靠谱。

程序员日常使用？
……调试蓝屏？整驱动？
不折腾会日进内核的苟屁游戏。别的日常应用撑死开虚拟机。

@zhxjdwh 真不够用会影响工作，那直接多申请几台机器不就好了。
要是搞不定服务器网络，最后给你多几台物理机，那是公司的事。

@JoeoooLAI 这是大多数人员正常的默认思路，但对开发者来说，对自己的机器管控能力经常是强过专业 IT 对整个网络中单台机器的程度的，配置开发环境之类迟早也得自己经手负责；用公司的机器，除非是网络问题，要挂了一样不可能随便免除责任风险。（慢就怪电脑……不怕真给你上顶配让你没借口？）所以如果有可能（保密和安全策略另说），只要性能不是烂太多，我还是喜欢用自己的机器。
但是自己专门去配就免了，不说设备成本的问题，要不记入工作时间就是纯粹多找的工作量，还不方便在工位以外的地方用。

Typo：可变性绑定(non immutable binding) →非可变性绑定(immutable binding)
（草，错位了……）

多跑个题，考虑到语言设计者本身的理解偏差的话，真要深层挖起来这里其实是有点其它方面的意思的。
不同 C-like 这种直接在语法上明确区分构造而不会混淆的设计，Scheme 这种全局使用近似的语法却单独对顶级(top level) 上下文约定的设计显然会把语言搞复杂。
这样做的显然是有目的的。我的理解是，这是要同时支持 REPL 的解释党和编译党的妥协。
Scheme 的特殊规则首先是顶级的 define 在绑定已存在时和 set! 等价，也就是一个绑定构造(binding construct) 被替换为赋值。这在 REPL 加载同一个源文件时比较方便。（考虑到 define 首先总能被当作是个 绑定构造，倒不会引起 Python 那么大的混乱。）
与此相对，非顶级的内部定义(internal definition) 则被认为明确地只是绑定构造而不是赋值。这允许 define 被明确地被实现为 letrec* 这种可变性绑定(non immutable binding) 的语法糖。变量绑定的存在性和名称解析的错误的因果性使后者的语义中隐含一种顺序上的限制，保证内部定义能进行这样的语法变换。这实质上给允许“编译”提供一种保证。
Python 同样有这样琐碎的问题：如何保证变量绑定的存在性能在早期被确定？不像 Scheme 这种长期两派党争下可以有简单妥协，Python 一开始基本就是 CPython 一家说了算，而其中提供 LOAD_FAST/LOAD_DEREF 之类的实现细节是否容易被静态确定以及 CPython 的“编译”倾向混在一起，客观上加剧了语言设计上的混乱。
从语言设计的角度，这里主要的本质差异是变量绑定所在的上下文不同。
Scheme 这样的 LISP 变体中，提供绑定的上下文数据结构称为环境(environment) ，传统上是表示变量绑定映射的关联列表(associated list) ，但实际上不要求明确内部的具体数据结构实现，只要提供能确定名称对应的实体的接口即可。
如 Scheme 这种顶级绑定放在顶级环境和 letrec* 这样依赖的 lambda 的局部环境(local environment) 是原则上不一样的，前者是“全局”，后者是（闭包的）“局部”。
（对应地，Python 里有不同的 namespace ； Python 的 environment 概念只是绑定的集合。）
但区分不同环境的这种设计并非原则上必要。全局环境在实现中的唯一本质区别保证开放(open) 即不总是需要具有源代码局部就能确定有限集合的绑定，而闭包里的局部环境则不是（只要不是打算让一个翻译单元支持翻译半个闭包的语法构造）。然而谁也没说闭包环境中枚举绑定的操作就该是 deterministic 的，只要名称解析能保证 total （可终止）。因为，枚举所有变量绑定根本就不是一个环境需要支持的常规操作——至少被静态绑定的闭包的变量就不是。如果需要反射变量本身的信息，则需要其它和实现相关的辅助操作，如 MIT Scheme 的 procedure-enviornment。这种操作的存在会暴露一些脱离传统闭包语义的实现细节，可能影响用户程序的可观察行为而使语法变换不能保证语义等价，反而会阻碍编译（所以往往只是作为调试辅助接口来用）。
另一方面，允许语言设计这样区分环境的现实是，这些语言并没有把环境暴露给用户操作的一等对象(first-class object) ，即提供一等环境(first-class environment) 。也正因为是这样，区分底层的环境不会让语言特性的复杂性失控（比如至少需要提供完全不同的两套 eval ……更别说如 R5RS 的残废 eval 本身就已经够让编译党抓狂了，以至于 Stalin 这样的实现停留在 R4RS ）。但这是以用户程序的表达能力缺失为代价的。例如，Scheme 的宏不能直接和用户定义的环境交互，也无法作为一等对象像过程这样的普通函数一样被作为参数传递或作为返回值。当然，提供宏来变通这种设计，本身就是隐含了“编译优先”的思路了。这某种意义上是一种过度优化，因为一等环境原则上不阻碍对闭包代码进行编译——本质上这里只是允许“尽早”而非严格静态确定绑定（如 J.Shutt 在 Kernel 语言中提供的 $let-safe ）。
至于 Python 连宏都没有……就略过算了。
为啥要多在乎某些语言设计者的肤浅的个别理解呢？

@ethego 关于区分读写……如果一个语言不要求明确 identity 也不在显式类型系统上暴露（而要求用户需要保证 const correctness 之类的 type safe ）的话，其实是很偏向实现细节且并不总是那么容易自然推理出来的东西。
很多用户都已经习惯了这些设计，实现也是这样搞的，reference 或者 spec 里反而不写出来了，这种风格我只能表示呵呵。要么直接写清楚，要么都不保证，哪个都比现在这种做法干净。
（包括 Scheme R7RS 比之前多明确某些特定的 variable 是不是具有 location，也有点设计过度了。）

@ethego 如果不说 Python，照常理当然应该这样（捕获变量和什么时候引入声明没逻辑上的依赖，本来就该正交），但 Python 在结果上就是不按这条路来有啥办法……
Python 不是个人作品，所以讲理由的时候还是按官方的正式文档来，况且尽管奇葩，现在的文档用的那套逻辑上确实能自圆其说。设计者另外的表示就算意图再明确，在文档修正前只能作为间接参考。（我怀疑 Py 烂摊子太多，根本就没人管得上这个。）

不会自主解决滚挂的，先 WSL 练手（还有一些特有问题能让你多练练……）。

如果没有约定自备机器，提供机器一般是公司 IT 的职能流程的分内事。自己配机器接入工作环境还可能有安全问题。经过许可了嘛？
因为工作需要升级环境的成本原本也理应由公司承担。自己花钱给公司减负，是出资人吗。
除非只是你一个人这样（这种情况显然项目资源安排很有槽点……），公司提供编译服务器远程提交比较有效，资源也可以共享。

楼上链接错了，https://www.v2ex.com/t/626109#reply51。

@FrankHB 我就是清楚“替换成列表没有问题的原因在于对于 list 成员的操作亦然属于只读 list 而不是写 list”（实际上还不仅是对 list ）才有这里的奇葩规则混在一起的结论，因为真没发现能通过依赖这条路径就可以推出这里出的问题——这是目前 Python reference 里直接明确的东西。
反过来，即便认为和 immutability 直接扯上关系的推理更直白，也覆盖不了 reference 里已有的描述，特别是不能解释清楚什么时候出现具体什么错误，一样至少需要这里用到的名称解析规则。
所以需要改动 reference 才能支持你的推理。
（我其实我同意按你想要的说法在直觉上还更容易让人明白一点；但 Py 特么现在就用的不是这个理由，那就凉拌吧，我也就不去找麻烦了……）
GvR 的邮件里的说法不管是否正确地反映了他想要的东西，都不可能取代正式文档的表述（而且这人在 PL 的一般议题上误会和偷换概念不是没前科的，要他支持 PTC，大讲了一通 TCO 如何如何，最终却认怂 feel educated 了）。
至于“这道题”，这就是送分题（区分 mutable，或至少按默认局部作用域规则一致地 capture ），Python 在搞混 binding construct/assignment 的情况下继续找事情，所以说特别奇葩。

题外话，关于子对象 mutablity 一般应该怎么搞的问题还是挺麻烦的：
https://www.v2ex.com/t/626109#reply76