My future of programming

正常的题目应该是 the future of programming 才对,
不过我想个人套路终归会被认为是旁门左道, 不少人并不喜欢,
再者说, 编程探索的方向有不少, Cirru 只是很窄的一个方向.
大概在编译器, 文本语法, IDE 这些方向依然会是改进的主流.
半图形编程嘛, 太奇怪, 并且也不通用, 也许还能把人吓怕了.
但我仍是想把本身的想法整理出来, 而且但愿我是对的.

语法的烦恼

你能够暂且认为我有代码洁癖, 相信不少人也是有的, 甚至各不同,
其实我最初上手的语言是 Python, 缩进的, 语法很简洁,
无论怎样, 我对 C 风格的语法一直有反感, 有着很硌脚的感受.
因而我去思考怎么人类才能写更少的代码, 而完成对应的工做.
个人结论大概是, 代码的布局应该有算法来控制, 避免人类手写.

Cirru 出发点就是用 Canvas 绘制语法树, 而后直接编辑语法树,
如今为了方便使用, 实际上用了 DOM, 但仍是尽可能让布局更漂亮一些.
而这样的结构其实很契合 Lisp 的风格, 而同时使用自动布局算法.
因此这基本就是我对于程序的理解, 写一棵语法树, 而后运行,
按照表达式增删改查, 不是一个个字符一行行文本啊, 而是有结构的树.

文件的麻烦

"文件"这个概念已经在程序员脑子里深深扎根, 我要攻击, 恐怕是叛逆,
来看一些场景吧, 我说 Clojure, namespace 的用法,
namespace 跟文件是对应的, 因此, 其实两份信息, 其中一份是冗余的,
若是改变了文件名, 对应的 namespace 也就须要更改,
通常程序当中出现这种状况, 咱们会设置函数, 响应式地改变第二个值,
但文件这种存在, 脱离于程序语法树, 没法被控制, 信息分散在两个 scope.
这中间确实存在一些麻烦, 或者说冗余, 只是未必让人以为严重.

然而站在个人角度看, 或者说, 逆向思惟吧, 若是没有文件呢?
namespace 是管理代码的手段, 问题的本源是, 函数太多, 不方便管理,
若是没有文件, 咱们有没有办法管理数量上百上千上万的函数名?
我以为能够, 办法依然是 Group 的概念, 可是为何必定要用文件?
好比你在浏览器收藏上千个书签, 能够用文件夹分割, 但不须要真的文件,
文件是能够被替换的实现, 仅仅是须要个 Group, 怎么样均可以.
并且, 若是咱们能搜索, 好比 Google 当中那么多数据, 不用文件夹依然能找到.
因此真实的问题是, 大量数据, 怎样管理, 怎样查找?

程序是什么?

从文件的反思就延伸到这个问题, 你究竟怎样看待程序, 程序是什么?
咱们知道存在高级语言低级语言的分别, 知道编程语言和机器码的分别,
我还截了一些图用来对比 http://weibo.com/1651843872/E...

首先 Quicksort 算法, 有个我彻底看不懂的汇编的版本,
汇编对应的是 CPU 指令, 或者稍微高级一些, 包含简单的标记, 操做, 移动等等:

而后是稍微高级一些的 C, 函数的概念已经有了, 还有 for/while 的概念,
这就是结构化编程的开始, 这些经常使用的流程控制语句涵盖了大量场景,
同时咱们不用一直顾虑底层的硬件到底是怎样工做的, 只要知道程序的结构如何设计:

Ruby 引入了混合范式的抽象, 程序进一步简化, 这当中是混用的:

最后一个是我最佩服的 Haskell 的例子, 几乎是数学化的表述,
这是能够运行的代码, 性能尽管不高, 可是抽象以后彻底不像是第一种了.

我想说的是 Quicksort 一个算法, 有那么多种程序的结构, 你想到了什么?

我对程序的理解

在我看来, 对于程序你们能够有着不少不一样的见解, 彻底能够,
也所以, 我以为找到适合本身的一种抽象尤其难得.
熟悉个人人知道我鼓吹函数式编程, 也就是偏向 Haskell, 虽然不完全...
在个人眼里, 程序是数据之间相互依赖的关系造成的复杂结构,
怎么说, 我举一个 Clojure 的例子, 好比个人程序计算 c:

(defn c [a b]
  (+ a b))

那么这里的 c 依赖 a 和 b, 只要拿到两个依赖, c 就有解,
找一个具体的例子, 下载文件, 这中间依赖好几个步骤,
当全部的三个步骤完成, 那么下载文件的程序也就完成了.
而这里特殊的是, 它的依赖是用反作用写的, 并且限定了顺序,

(defn download-file [url]
  (request-file url)
  (save-file)
  (print-success))

也就是说, print-success 依赖 save-file, 然后者又依赖 request-url.
在 Haskell 当中反作用被封装, 这一点尤其夸张... 但确实这个道理.
还有一些并行计算的例子, 这种依赖关系还能派上用场..

以此我认为程序就是函数和数据等等内容依赖关系造成的复杂形态.
推论就是, 我应该基于函数基于数据的依赖来编写程序,
这个提及的比较抽象, 可是写 Clojure 确实慢慢能积累这种感受.

Stack Editor

Stack Editor 的理念, 主要基于函数来管理程序, 同时弱化文件的概念.
当你须要编辑函数, 你尽可能经过函数之间的依赖关系之间打开函数,
你也能够把函数放在侧边栏, 方便在不一样的函数之间切换,
而你不须要去管文件怎么建立, 函数摆放的顺序谁先谁后,
你要作的是定义好依赖关系, 而具体怎样保存, 那是编译器的工做.

我知道根据依赖关系, 咱们能分析出更多关于程序的细节,
编译器能够比咱们更清楚地了解程序每个细节, 从而给出指导.
这些将来依然能改进, 这个版本我固然还作不到的.

人脑的极限

还有一点很是重要的是, 咱们须要了解本身的弱点在什么地方,
特别是面对机器所拥有的海量的内存和强大的计算能力,
人类大脑依赖的是神经元信号分析模式, 而后得出一些结果,
而越是抽象的内容, 越是须要消耗脑力去认为建立大量的联系,
很显然, 人脑并非处理这类问题最合适的计算单元,
于是我认为编程当中复杂的逻辑关系以及依赖关系不适合人工处理.

而编程当中这类问题并很多, 特别是大型软件会遭遇的种种问题.
英文社区有篇文章概括了一些, 我很是认同的做者, 大体列举了这些:
http://www.chris-granger.com/...

• Programming is unobservable

• Programming is indirect

• Programming is incidentally complex

关键的问题就是, 编程不像是咱们平常当中遇到的可观可感的各种问题,
不像是几十万年来咱们从生活中积累, 大脑适应去解决的那些问题,
流动在代码当中复杂的关系, 可让一个没有通过编程训练的人一筹莫展!

于是个人见解, 应该尽量把更适合机器处理的部分分离出来,
而后写成程序让计算机完成, 而人类尽可能只作本身擅长的事情.
用工具去生成代码和管理函数只是开始的几个步骤,
我应该在将来会更多地思考图形编程相关的问题, 但愿能给出一些成果.

可组合性

用用户体验的话说, 应该是"最小学习成本", 用户不须要学习额外的内容,
但放在计算机的领域当中, 作减法每每不能直接砍掉东西.
好比说编程语言 A 有一系列功能, 但为了简单, 不能说就直接去掉某些,
而是, 应该像是数学当中, 若是概念要去掉, 它应该是从其余概念推导获得,
那么, 就像 Scheme 的规范能制定出一个精简的版本, 同时功能依然全面.

而达成这种目标, 就值得让每一个单元都具有足够强大的组合能力,
这样, 才能最大限度地复用, 最大限度地用有限的元素组合出更多功能.
在我看来"一切皆是表达式"是很是重要的一个特性!
"一切皆是表达式"意味着每一个单元均可以被组合, 能够在全部恰当的地方使用,
在命令式语言当中, 或者自定义的 DSL 当中, 每每这项功能是残缺的.

就像是数学, 数字能够扩展用在几乎全部的计算当中, 会计算就能上手新事物.
而这项特性一旦丧失, 当你面对新事物, 那就是全新的事物.
显然咱们但愿学到一个 x 就能拿 x 组合已有的 y 创造 x * y 中可能,
而不是一个 x 学完以后, 咱们只有 x + y 中种新的手段.考虑的将来编程会怎样, 我固然是但愿向前者靠拢的, 带来更多可能.