和 PHP 一样就够劝退了。

GUI 工具看上去有点可以，虽然口味可能有点复古。

语言设计没什么新的地方。
吹得最响亮的所谓 supporting Natural Language，看着一点都不像 natural language，语法（假设存在的话）和语法规则还都啰嗦。
Eval() 还是拿字符串当参数。

不过不少迹象表明作者在 PL 的很几个基本的方面就是彻底的外行，例如：
糊个 GC 就想避免 memory leaks ；
使用 delete these variables using the assignment statement 这样的说法；
把 Variables, Lists, Objects and Functions 并列在一起讲；
所谓 Weakly typed，还放在 Dynamic 下；
所谓 Native Object-Oriented Support，还把 Polymorphism 和 Inheritance 并列，甚至还能包括 Packages、Reflection and Meta-programming （ OOP 的 reflection and metaprogramming 或许不是问题，但之前一开始拿出来单独当特色说过了嘛……）。

某几个 Simple 的介绍尤其可笑：
把 Call Function before the definition 当 Simple 标榜说明不怎么有逻辑学基础。
把 8-bit clean 当 Simple 说明不太有良好的工程习惯。
把 Not Case-Sensitive 当作 Simple 来吹则让人更加怀疑是不是 natural language 的外行了。

所见即所得……<s>Firefox</s>Basilisk + MozArchiver 无所畏惧。
转截图再转 pdf 是在此之后的后处理的问题，而且肯定是有损的。直接转 PDF 的插件也有，不过我也没一个个试过效果差多少。

二进制分发体积小到一定程度以下就没多大差别了，至少 PC 软件是这样。都 9102 了，又不缺几 K 的带宽。至于少依赖，这算是 Windows 下缺乏依赖管理给逼的，本来就是妥协而不是优势——而且再容易也还得一个个下载，哪有一行命令解决省事。

@Youngxj 那是自掘坟墓，早死早超生。

这个系列的特色就是对话体，不需要你阅读的时候同时自己另外组织思路。
好处主要是降低入门难度，只要读者能习惯。
坏处是这种体裁根本没法 hold 住所有重要的主题（知识密度低算是个次要的副作用），放纵读者习惯到处都是 hint 的环境而欠缺自己观察的能力，无助于积累经验，思维不够自觉发散的会少看到很多东西（虽然这个比较吃天赋，还是能训练的）。一旦容易的东西都讲得差不多了，背景知识难度一上去，可能就会被隐藏的难度卡壳。
Scheme 本身比较水，问题应该还不大。我见到过看 The Little Typer 然后没看出某个变换实质讲的是 beta reduction 但没明确指出来，结果读起来一下子觉得直接云里雾里了的读者。

另外关于 Scheme，有几个特别的这里提到的这些书都不会提的点：
如果要知道实际在用的东西是什么，应该看 RnRS （反正也不长）。看个大概再回来对比 INTRODUCTION，然后会发现一些设计意义上根本的矛盾。
可以再试着去理解 R6RS 的反复，编译和解释阵营的分裂之类的“社会问题”。因为其它语言的学习过程中基本都会欠缺这样的例子，这种经验可能比熟悉怎么用具体的语言更重要。

如果要搞 PL 想测试自己天赋的：
你应该能总结出就 Scheme 的 lambda the ultimate... 的 flavor 本身，实际还是有很多水的地方，比如 undelimited continuation 为什么无论如何都不实用；不管是 lambda 还是 Scheme 暴露的 first-class continuation，实际上显然不够 ultimate ……
你还能应该隐约认识到至少传统 LISP 表面上看起来简明的设计（如 quote 和过度依赖 alist ）在语用上有一些无法避免的不自然的问题，这不是用户的错。
（具体文献的位置就不列了，省得影响学习效果。）

@yijuechen 跟用不用得上语言没多少关系。
@ech0x 虽然目的是这样没错，但真这样想你就上当了。

为什么都 9102 了还要强调用 Scheme 的 SICP ？
关键是用其它语言讲的入门读物相比起来实在比它屎得太多了，包括不用 Scheme 的 SICP （这个例子也说明作者的知识背景的影响可能没多数人想象中的那么大）。
https://gist.github.com/FrankHB/00731fedf07b4ea271afa70a5cdc8d9d#%E6%96%87%E7%8C%AE%E7%9B%B8%E5%85%B3

“云”

Arch Wrong
WSL+Arch Yes
（手动狗头

@lihongjie0209
1.我认为“存储无关”决定架构优劣这是教条，并且有悖常理。
因为架构设计是服务于业务的，是不是允许系统设计依赖甚至鼓励依赖某个子系统（不管是持久化层还是你这里说更具体的“存储”这样的实现）的特征以便使系统容易具有其它优势，这根本还是业务需求说了算。
而且，强制要求先划分出存储还可能使实现容易违反一些其它更一般的普遍原则，比如 Principle of least privilege。
2.决定存储在哪里实现本身就是需要设计决策确定的一个问题，不能总是简单地排除出业务之外。
3.更一般地，数据库实际上不过是存储（或者持久化层）的一种实现。预先要求依赖某种数据库也是应该在普遍的架构设计中避免的——只不过这个主题的题设已经限定了数据库这个背景而已。
4.设计是需求的解。你的“高于需求”的理念不符合工程上一般意义的认知，这个矛盾看来需要你在落实设计之前解决。
5.设计的变化不一定成问题，但是为了变化付出太大的成本可能成问题。（另外，明确架构设计的一个作用就是为了避免这种成本太大。）不是任意的变化都应该是被无条件接受的。
6.你似乎认为测试数据库总是困难的，测试别的模块总是比测试数据库简单。不过事实上恐怕未必总是如此。
的确有几种强行让业务逻辑看起来总是更容易测试的设计套路，但是因为会限制表达能力，并不是每个业务领域都允许这样。
7.这点原则上我同意你的意见，虽然严格来讲测试业务逻辑不总是单元测试，这是和这里内容没有直接关系的次要话题。我的提法有些不够清楚，原意是指整个系统中的其它模块。

@reus 你光建模不实现？那还有个什么鬼匹配问题？
否则你糊到建模工具上的东西有不落实到一个非纯 DDL 的实现上的？
依赖什么智熄关系模型久了就是看什么都变成钉子了。滥用存储过程算是连带晚期症状。
而且威力实际就是比滥用面向对象大，因为烂的面向对象设计很容易让代码糊得长到可疑而露马脚，而烂的关系模型花样多了去了。

新的智商税蓝海罢了。不过也快变红海了。
倒是看着一坨连 latent typing 都没概念的半路出家的职业码农，或许 PL 培训还有意义？
@anonymous256 跟编译器没关系。你撸个 REPL 照样可以有 static typing 也可以往上接着糊 typechecker。
@silkriver 不可见空白符折腾不干净还有脸谈可读性的也没谁了。
@lidongyx 就 Py 这素质也好意思通识……
像 SICP 的 Py 版，为了迁就讲 Py 特有的一类恶臭设计把自己都给讲傻了，晚节不保： http://tieba.baidu.com/f?ct=335675392&z=6113807981&sc=125374630106#125374630106
@abcbuzhiming 需要重构本来就是设计烂。正常的设计就是自己连带把要用的类型约束加上。
不过一般码农确实没什么基础能按项目需求撸个类型系统往上凑，而更尴尬的是面对 The Little Typer 之类入门读物水货，科班教育的基础通常还远远不够……
@ipwx 不管是文言文还是白话文，技术上就是 NLP 都糊不干净的鸡肋。
当然，所有自然语言多少都是没有设计只有演化的情况，都有类似的缺陷。只能说哪个比哪个稍微顶用一点罢了。
至于 Py 之流不靠确切地项目需求而是靠炒作流量流行的爆款语言，作为 PL，就满足解决问题不瞎添乱这个需求来看，初始格调就太低了。看看有几个这类语言的用户分得清什么叫静态类型什么叫强类型就知道，大多都是连为什么顶用都稀里糊涂的，鬼知道再营销个爆款会不会见风使舵弃之如敝屣了。（虽然现实是不管是 C 还是 js 的用户这方面也好不到哪去。）
而典型的真正通用的 PL 很难让初学者立刻发挥价值，所以扩大用户基数并没多大卵用。
或者说白了，这类语言本来就没顶用到有脸和白话文相提并论。是不是 dssq 姑且不论，但决定它能不能生存下来是看它本身的质量，而不是用它的人，更不是用它的人有多少。
@0xABCD 现在的市场就是想要把它们往通用目的语言上推，不过设计是不是够用。不过说白了原来 C 也是这样。
@lolizeppelin 拉倒吧，干掉 POSIX shell 和 cmd 在各个发行版到处预装了再说。
否则一样弟弟（甚至未必打得过 awk ）。
（想想 ps1 都还各种中道崩殂呢，呵呵……）
@areless 不限定用户基数的话，近十年冒出来的网红远不止 Py 一个，Ruby/Lua/Haskell/Golang/Scala/Dart/Kotlin/Swift/Nim 之类的都可以算。里面有多少货也是不一而足。真正在预设目标中没有妥协而且基本达到了预期目的（而不那么像网红）的少得多，想了下大概 Rust 和 TS。（姑且忽略红不起来的 F# 什么的……）
Py 特殊在能持续不管内容吸引流量。而且比起资格比别的网红其实还老一点。所以确切地说，更像是流量带明星……

兴趣

就算不是 Android 开发者，看到运营商流量劫持的一堆 iqiyi://ctrip://newsapp://之类然后 net::ERR_UNKNOWN_URL_SCHEME 的就知道至少肯定能实现……┴─┴︵╰（‵□′╰）

草，眼看着 275L 然后就把 > 的位置贴错了几个，，，

@ertxn .
你说的我觉得完全没有问题，问题是就算是“长期维护”，我能保证这个镜像能在多少年呢？
> 除非镜像站被你个人所有，或你持续有义务代表对镜像站负责的组织，你不需要对这些问题负责。

也许毕业前都可以和老师和领导打嘴炮磨圈圈没问题，算上最多也就 7 年时间。
> 7 年都够一个系统发行版寿终正寝了，只坚持了 7 年说“长期”也并没有多少问题。

那等毕业了呢，离校了呢，我都不敢保证几年后学弟学妹们是否像我一样热爱这些，就更不可能保证“长久的稳定的”运行。
> 实在不理解为什么轮得到你来保证。

可能说起来会被看作笑话，但是是很现实的问题我觉得。大站的如 TUNA 和 USTC@LUG 都可能不一定敢说自己能百分之一百的一直运行下去不出意外，更何况我们一个末流 xxx 大学的一个站点。
> 没法维持运营并不是什么难理解的事情。但是关于保证责任的问题，我认为你或许真的需要和同行交流确认一下。

但是至少我们存在的时间里我能做到说你网速好的话校外能跑到 20m/s，可能比如用 arch 的话能看到 80m/s 更新包时候的情景。
> 结合实际情况，这是某种程度上的资源浪费。
现在恐怕大多数公网用户都没这种带宽的一半，而一般用户期望的速率可能不会超过这个的 1/5。（我用几个大站的源更新 Arch 也不过几 MB/s，并没觉得慢——也就抱怨一下 Qt 为什么这么大。）
技术上来讲，并不能指望一个普通的镜像源能在公网上实现准确的 QoS 而确保带宽用到最该被依赖的地方，所以请注意开源节流量力而为。

> 我们提交到官方源算是对社区的一个回馈，饮水思源。目前有能力替两个大校分担流量，我们会选择全力以赴。
我看到你多次强调了分担流量。你在这里似乎对提供镜像服务的动机的理解上有些偏差。
贡献流量不是建立镜像源的直接的目的；目的是满足社区对软件分发服务的需求。这些需求包含不同的方面，并非都能通过贡献流量来满足，多余的流量供给也并不能弥补其它不足。
充足的流量确实是提供服务质量的保证之一，但更根本的是服务的可用性——让用户断线重连不得不重复下载不完整的包是无效的流量贡献。
对大多数公网用户，使用镜像源的首要的理由是为了更好的（稳定高速的）传输体验，这也包括了避免不必要的手动配置变更。他们原则上不需要在乎你花费的流量具体有多少。与其贡献更多的流量，维持更稳定持久的服务对他们来说更有意义。
对其它源来讲，你贡献更多的流量可能对他们节约成本而维持服务的可用性有益——前提是确实合理地配置了资源。如果把别的学校里本来可以搞好满足需求的内网镜像源用户都赶过来扎堆用你的公网镜像源，那是有害的——浪费资源，或者至少增加了分配资源的成本。
而评价资源是否合理配置，根本上也是看满足预期的用户需求。你不可能绕过这点只论流量来论贡献程度。流量是投入的一部分，并不等于实际的产出：你再怎么全力以赴地烧钱（且不论是哪来的），也并不表示社区会享受到你的全力以赴的贡献。

> 不过还是那句话，所有以实际情况为准，可能是杞人忧天，但是我以为这些情况都要考虑进去。规矩是死的人是活的。
作为维护者，有些事你管不了，也没人指望你能管；你看起来是想多了。
但是另外有一些事，即使对一些用户来讲是常识性的，你看起来仍然想得太少了。

@ertxn 你说的内容槽点太多了。
> 很多人应该做的不是在那里说风凉话而是实际拿出点行动做点什么。
事实表明你没资格定义什么叫“风凉话”，什么又是实际拿点的“行动”。参见 #281。

> 诚然限速后添加到官方源确实很不好，
不要避重就轻，特别还是以镜像源维护者的身份说话。

> 但是从官方源移除意味着为其他的镜像站增加了本来不必要的负担。
根据？
你是否想过，有的用户（特别是新手）因为源慢很可能就直接放弃使用了，这是损害了谁的利益，增加了谁的负担？

> 那么照楼上一些人的观点我是不是也可以考虑申请从官方列表中移除我维护的那个我倾尽了心血的镜像站呢？
如果你无力做到不损害非特定公众的体验，我敦促你在官方镜像列表中移除。
理智的用户不会因为移除一个镜像站点而对此不满，如果你清晰地表达了理由，他们甚至可能感谢你——避免了突然服务不可用的应急成本增加的风险。

> 说不定哪天我又被老师问有没有给用户限制的问题我又该怎么回答呢？
这是你作为镜像站点维护人员应该解决的内部问题。
你当然也可以用缺乏资源支持作为关闭站点的合理理由告知公众——供应链上的涉众的理解和支持，这本身也是一种资源。

> 我觉得不现实而且是很不负责任的表现，
是否现实可以自行判断，但若因此造成本楼中损害不特定公众的后果，那么就真是广而告之不负责任了。
另外，如果因为分摊资源服务公网用户而使学校内部的本应最需要你服务的用户的体验受损，那也是一种不负责任。

> 这样的话会使得其他高校镜像站的负担日益加重。
缺乏根据。除了上面说了的以外，还有一点要注意：高校镜像站不一定要开放公网使用。
即使只是服务校内同学老师，同样也能减轻其它镜像站点的公网流量负担。
对这点问题缺乏认知，使我开始有点怀疑你是不是确实地理解了你日常维护的工作的意义何在。

> 不过如果哪天情非所愿还必须申请移除呢？
是否及时避免损害用户的行为，体现出负责的程度。

> 万一我忘记了移除一两天会不会又被想西北农林这样挂起来打的呢？
视后果而定。
是否真的只是疏忽忘记，还是一开始就没搞清楚自己该干什么，一般不难确认。

> 接下来说点实际情况：目前我们是多个大发行版的官方源之一，单论比如 TeX 很多人认为没什么流量可能，但是也会达到每天几个 TB 的样子，然而还算少的，更不用提带宽占用冠军 CentOS。
如果是因为维护策略的原因，一开始就没限制并发数或者没有协调好其它的资源配额，而导致外网用户不能享受预期中公平合理的镜像服务的话，那么维护者接锅。

> 说不定哪天就又要开始考虑屏蔽迅雷用户，屏蔽国产浏览器用户，最终限制外网用户，屏蔽外网用户。
限制超过资源限定的用户是合理的运营策略；限制公网用户的资源配额、优先服务内部网络的用户也是合理的；但无原则地、欠缺逻辑（因果关系和关于责任承担的原则）地限制非特定群体用户的歧视性策略并不能挽回上面的这个锅。

> 还是那句话很多人你说的有没有道理，我必须承认有一定道理，但是实际情况可能没你想的那么轻松罢了，楼上一些人在这打嘴炮的有这些功夫你联系下开源镜像站的维护组织出钱出力出时间都行也比在这当键盘侠图嘴上痛快开的要让人尊重。
几乎每句都有槽点，还有不少和自己身份截然冲突的观点表达——我真不知道你有何立场来指点潜在的用户该如何做。
请先做好自己的事。

@CYKun 不管出于什么动机，跟这个镜像站八竿子打不着的不确定公众的体验就是因为维护者（而不是镜像服务本身）的素质问题被以不小的概率降低了。他们本不应该受到这样的对待。
这种明知故犯损人不见得利己的人为因素的做法，显然是欠缺公德的行为。
手动换不换源，官方提不提 issue，提不提供捐赠，这都各人自决的事项，并非强制没有选项的义务。即便你要站在莫须有的道德制高点上谴责，这也都是私德问题，跟上面的行为没什么可比性。而且，本来不是用户而装作是用户去做这这样“有建设性”的事而导致报道有偏差和 /或浪费资源，还会造成另外的缺乏公德的问题。
退一万步讲，不管这些选择，这些事项显然和公众能不能对缺德问题谴责没有因果关系。所以你的逻辑呢？
和你对所谓“建设性”的想当然的理解正相反，用舆论监督纠正不文明的行为，这恰恰是维护公德的正当有效操作，是有“建设性”的。舆论的有效性也从这楼里通报的后续处理措施中体现出来了，啪啪啪打脸是否愉悦？
你自身就欠缺如何纠正缺德行为甚至何谓缺德的道德常识，反倒好意思扣帽子以所谓缺乏“建设性”为由质疑，传播伪劣的社会价值导向？你能不能和给你点“有用”的一起深刻反省表示一下，挽回这部分被你祸害的公德？