文件大小，创建时间属于文件本身的属性，而文件名是程序员指定的概念。
OS默认是按文件名的头字母排序的，这点很不爽。特别是，当你需要做一些代码展示的时候（比如：做presentation的时候，examples 文件夹里有很多 demo文件，它们总得有个先后顺序）
ok，那权限，打开方式（MIME type），文件标记呢？
这是某个操作系统的限制，我不觉得和编程语言有什么关系。甚至不用搞什么 hack，你完全可以指定 ls Finder FileExplorer 这些工具如何排列文件。
不仅仅是操作系统，比如：我现在要在Github上做演示。
那你完全可以自己建个 index 页面，超链接到各个 demo，甚至可以针对不同需求的人建立不同顺序的 index。不要说手动什么的，这些完全可以自动化
根本不存在 针对不同需求的人建立不同顺序 的问题，因为这个顺序本来就是 由简到难 或 有功能依赖。
比如：我要 先演示 untyped lambda，再演示 typed lambda，再演示 System F，再演示 System F<: 然后再是 System Fω<: ，。。。它们之间有严格的偏序关系（因为它们之间是特性叠加）。
那我以 Homotopy Type Theory 举例，它混合了 MLTT 和 Homotopy Theory，有 MLTT 基础的，多是搞定理证明软件的，可以直接跳过介绍 MLTT 看 Homotopy Theory，有 Homotopy 基础的，一般是搞 Topology 抽象代数的，通常不一定熟悉 Type Theory。这些不就有了区分不同需求的需要了么？更有甚者，一些 MLTT 的概念要和 Topology 对照才能讲清楚，那就有哪个先讲的问题了。又比如 Univalence Axiom，一些 MLTT 的改变涉及了这个，然而又有众多关于 Univalent 的 topic 要统一讲，而这些讲解都要用 MLTT 的概念，这种循环依赖的关系并不难靠直接一个顺序来解决。
演讲demo的顺序，是在准备演讲稿的时候就确定了的（自然是 尽可能的“由简到难”）
所以我希望在演讲的时候 examples 文件夹里的文件能按照我的意愿排好序。
如果是不同的人群，显然就要使用不同的exanples文件夹了。
那相同之处的重复利用不可以么？创建软链接？这不就是一种另类的 index 么？
任何学科都存在循环依赖问题。
但好的编书者会尽可能的减少循环依赖，尽可能把被依赖章节多的放到前面去。
这种东西重复利用的意义不大。
创建index说起来轻巧，但是要系统化支持可就难了。
比如：在treemacs里要支持，在os里要支持，在Github里要支持，在各种IDE里要支持。。。
而且还得提供专门的rename机制，就像rename文件名一样（相当于每个文件有两个文件名，一个是真正的文件名，一个用来处理偏序）。
除非国际标准能支持这种专门用来处理文件偏序关系的特殊tag，不过我至今没见过有这种标准化系统。
1 个赞
动态语言的优势永远不会消失，特别是原型开发。
这些代码往往之后会被废弃，并不考虑稳定性和可靠性，目的仅仅是用来验证idea。
动态类型语言的这种所谓能够快速进行原型开发的能力，根本上来自于它丰富的生态环境及社区，就是那些包罗万象的库，因为动态语言往往都是解释型语言，公开的语言造就了良好的生态环境。
但是当像 Go、Rust 之类的静态编译型语言采取类似策略之后，动态类型语言的快速原型开发优势也不明显了，动态性不够易部署能力来凑，强行五五开。
现在绝大多数语言都能做到 10 行代码以内写一个 helloworld web 服务，静态类型语言的开发效率优势在快速提升，而动态类型语言的开发效率却很难提升了，开发效率的差别已经很小了。当使用静态类型语言开发一个竞品，因为性能及易部署上的提升而取得竞争优势的时候，对动态类型语言才是一种不公平竞争。
“先用动态类型语言进行快速原型开发，等项目成功之后吸引来大量用户后再用其它语言重写，原型很廉价扔了也不可惜。” ------ 这是当年 ruby on rails 之类的语言为自己糟糕的性能搞的一套说辞。
事实是绝大部分项目即没有因为一无是处而被扔掉，也没有因为获得重大成功而被重写，它就这么继续存在着，在应付新需求和缝补性能问题之间煎熬，就是很多公司里普便存在的要么忍要么滚的项目。不过想到从个人的角度来说，至少可以一走了之，其实也就没什么了，反正也闹不出人命。
动态语言快速原型开发终究只是自己一时爽，有点负责心的话走之前要么把它 close 掉，要么重写完，虽然没有什么绩效，算是积德吧
3 个赞
这个世界上每天都有新的语言诞生和死去，如果一门语言够牛逼，自然会活到我去了解它的 那一天，千万别抱着怕错过好东西的心态。
对 Scala 不了解，除了工作中要用到，个人挑选研究（其实只是选择去了解而已）的语言 会遵循 2 个原则：
1, 不选择跟已掌握语言定位类似并且开发哲学相近的语言
所以学了 C/C++ 后，也基本不碰 Java 了，Scala 跟 Java 走得很近，所以也不打算去学了。
学了 Python 后也不碰 Ruby 了。
学一门语言就一定要去按这门语言去进行思考，这样可以增长见识，不会思维受限，而选择 一门差异巨大的语言，个人思想受到的冲击越大。
2, 不选择方言
所以学了 Lisp 后对 Scheme 也不会考虑。
学了 Javascript 也不碰 CoffeeScript，甚至连 TypeScript 都兴趣不大。
方言基本上是为了彻底实施某个理念而产生的，我把它看做是一种狂热，因为没有原始语言 的那种经过证明的生命力，很可能来得快去得也快。当然也还会去了解一下这个理念的来龙 去脉并进行应用。
那你对ocaml或haskell了解吗？ 我觉得scala跟他们更像。
nodejs算是JavaScript的方言呢？还是只算是一个函数库？
你们专业搞开发的，选择就考虑的多了，像我们这种半吊子编程爱好者，选择依据基本就是： 1. 看着顺眼， 2. 实际有点用处
ocaml haskell scala 这些我全部都只听过名字，从来没有去学过，如果我是一个计算机系的学生，我想我会每一门语言都花至少 1 个星期的业余时间去过一遍官方教程，最终只会从类似的语言中留下一门进行继续深入学习以及实际使用。
Node.js 算是 Javascript 这种语言的一个扩展，但是由于它在后台开发方面引入异步取得的突破性进展（2009年左右，能够推出一个全异步的开发平台真的是一个奇迹），以及基于浏览器端唯一的语言 Javascript，所以对于后端开发人员具有强烈的吸引力。
如果不是 Google 这位金主爸爸几乎在同一时间推出的 Golang，主流的前后端开发估计早被一统江山了。
在语言的选择上开发人员是用脚投票，除了很多大公司有很多现有的积累，不好轻易换道之外，创业公司（只要跟互联网粘点边的）清一色的 Golang 或 Node.js，因为 3-5 个人撑起整个后端的创业公司是很普便的。
恰恰相反，专业搞开发的会意识到选择一门语言是有很大的成本的，不管是心智负担成本、时间成本、机会成本。
学一门语言要不就是跟公司的业务很合拍，要不就是能够提升个人的效率。
所以开发人员会很矛盾，Golang、Node.js 搞公司项目是一把利器，但是几乎没有多少人打心眼里喜欢这些语言本身，大部门是当工具在使用。
而 C++、Lisp、Python、Rust 这些喜欢的人很多，但是当为新项目选择语言时，会很谨慎的选择它们，因为它们真的可以玩出花样来，团队项目最忌讳的就是有人玩花活，这种人玩几把就跑路的居多。一个项目 80% 的成本在维护期，所以一开始就要把控好，心痒想玩花活的时候要忍住，长远考虑。
用rust玩花活的都跪在borrow checker下了
rust 对 c++ 开发人员有致命的吸引力，还记得 c++ 0x 的梗，一堆大牛业余时间搞个新标准只会把观众的头发熬白。
rust 也算是根正苗红的一股清流了，客户端开发目前算是大成了，估计会有很多客户端项目用 rust 开发或重写，只是前几年迟迟不肯往后端发力，散失了很多想像空间。很期待嵌入式开发会成为 rust 的天下。