-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathindex.html
1364 lines (877 loc) · 99.5 KB
/
index.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE html>
<html lang="en-us">
<head>
<meta charset="UTF-8">
<title>Human by human-lang</title>
<meta name="viewport" content="width=device-width, initial-scale=1">
<link rel="stylesheet" type="text/css" href="stylesheets/normalize.css" media="screen">
<link href='http://fonts.googleapis.com/css?family=Open+Sans:400,700' rel='stylesheet' type='text/css'>
<link rel="stylesheet" type="text/css" href="stylesheets/stylesheet.css" media="screen">
<link rel="stylesheet" type="text/css" href="stylesheets/github-light.css" media="screen">
</head>
<body>
<section class="page-header">
<h1 class="project-name">Human</h1>
<h2 class="project-tagline">A programming language for humans.</h2>
<a href="https://github.com/human-lang/draft" class="btn">View on GitHub</a>
<a href="https://github.com/human-lang/draft/zipball/master" class="btn">Download .zip</a>
<a href="https://github.com/human-lang/draft/tarball/master" class="btn">Download .tar.gz</a>
</section>
<section class="main-content">
<h1>
<a id="the-design-draft-of-human-programming-language" class="anchor" href="#the-design-draft-of-human-programming-language" aria-hidden="true"><span class="octicon octicon-link"></span></a>The Design Draft Of Human Programming Language</h1>
<p>Human 编程语言设计草案。</p>
<h2>
<a id="当前编程语言存在的问题-及其解决方案概略描述" class="anchor" href="#%E5%BD%93%E5%89%8D%E7%BC%96%E7%A8%8B%E8%AF%AD%E8%A8%80%E5%AD%98%E5%9C%A8%E7%9A%84%E9%97%AE%E9%A2%98-%E5%8F%8A%E5%85%B6%E8%A7%A3%E5%86%B3%E6%96%B9%E6%A1%88%E6%A6%82%E7%95%A5%E6%8F%8F%E8%BF%B0" aria-hidden="true"><span class="octicon octicon-link"></span></a>当前编程语言存在的问题 及其解决方案概略描述</h2>
<h3>
<a id="本质问题-及其解决" class="anchor" href="#%E6%9C%AC%E8%B4%A8%E9%97%AE%E9%A2%98-%E5%8F%8A%E5%85%B6%E8%A7%A3%E5%86%B3" aria-hidden="true"><span class="octicon octicon-link"></span></a>本质问题 及其解决</h3>
<p>最主要和最本质的问题是没有从 <strong>人类思维本质</strong> 出发去设计，而是从机器或逻辑角度去设计编程语言。
我知道读者一定对什么是人类思维本质产生了疑问，而且会疑惑难道就没有别人想过这个问题吗。对此
我的声明是，本人的智识有限，还望各位读者多从接纳未知可能性的角度去多思考这个问题和模式。</p>
<p>略知晓编程语言历史的人都知道，目前存在的上千种编程语言中有两大高山，即 C 和 Lisp ，分别代表了
主流的命令式和函数式两种风格。C 一直是工业界主流大众语言，常用于系统编程。而 Lisp 则相对小众,
一般用于人工智能等方面。最近二十多年里比较流行的语言有 C++, Java, VB, C#, Objective-C, Haskell,
Erlang, Prolog, Python, Ruby, JavaScript, PHP, 还有近几年被创造出来的 CoffeeScript, Scala,
Elixir, Clojure, Rust 等。我们不难看出越新近的语言，会更多的融入 Lisp 的优点。有人说是越新的
编程语言越趋向于 Lisp 化，不过我更愿意相信是两者平分天下才是历史的趋势。</p>
<p>至于未来编程语言如何发展，在我们现在有了一定量的计算和存储能力后，我认为从 <strong>人类思维本质</strong> 出
发才能创造出和自然语言一样可以历经千年而不变其宗的编程语言，然后再把 SQL 和 CSS 等领域特定语言
(非图灵完全)构建于其之上，甚至把上游的汇编语言也反推导回去，就像我们去思考哲学问题一样。</p>
<h3>
<a id="类继承和原型继承等概念构建模式-及其解决方案" class="anchor" href="#%E7%B1%BB%E7%BB%A7%E6%89%BF%E5%92%8C%E5%8E%9F%E5%9E%8B%E7%BB%A7%E6%89%BF%E7%AD%89%E6%A6%82%E5%BF%B5%E6%9E%84%E5%BB%BA%E6%A8%A1%E5%BC%8F-%E5%8F%8A%E5%85%B6%E8%A7%A3%E5%86%B3%E6%96%B9%E6%A1%88" aria-hidden="true"><span class="octicon octicon-link"></span></a>类继承和原型继承等概念构建模式 及其解决方案</h3>
<ul>
<li>概念太抽象</li>
</ul>
<p>初次接触编程语言的人在学会基本语法后，接下来就是搞清楚 "类", "对象", "变量", "静态变量", "实例
变量" 等一大堆关于数据的抽象概念。这些概念及其关系在日常生活里没有大致相似的类比，因为编程语言
是用常规人类不擅长的逻辑去模拟现实世界的数据和关系，而不像小说和绘画等用自然语言或图像去模拟和
解释世界。</p>
<ul>
<li>类继承偏向强调以数据为思考中心</li>
</ul>
<p>类继承是人类发明的对客观世界的数据整理谱系，例如对生物界的"界门纲目科属种"垂直划分方法，对日常
生活的"美食电影娱乐酒店丽人结婚亲子购物健身"平铺划分方法，这些在本质上只是偏整理性质的数据产出
而已，软件核心关注的是如何达成用户的需求，也是一系列行为场景。数据是按照逻辑来变化的，在数据分
类中体现出的意图才是用户真正想要关心的，也即是数据和逻辑在一起才构成了本质。</p>
<ul>
<li>类继承示例 及其问题</li>
</ul>
<div class="highlight highlight-python"><pre><span class="pl-k">class</span> <span class="pl-en">Book</span>(<span class="pl-e"><span class="pl-c1">object</span></span>): <span class="pl-c"># 声明 Book 类</span>
<span class="pl-k">def</span> <span class="pl-en"><span class="pl-c1">__init__</span></span>(<span class="pl-smi">self</span>, <span class="pl-smi">name</span>, <span class="pl-smi">author</span>): <span class="pl-c"># 初始化函数，及其参数</span>
<span class="pl-v">self</span>.name <span class="pl-k">=</span> name <span class="pl-c"># 绑定 name 值</span>
<span class="pl-v">self</span>.author <span class="pl-k">=</span> author <span class="pl-c"># 绑定 author 值</span>
book1 <span class="pl-k">=</span> new Book(<span class="pl-smi">name</span><span class="pl-k">=</span><span class="pl-s"><span class="pl-pds">"</span>逻辑哲学论<span class="pl-pds">"</span></span>, <span class="pl-smi">author</span><span class="pl-k">=</span><span class="pl-s"><span class="pl-pds">"</span>维特根斯坦<span class="pl-pds">"</span></span>) <span class="pl-c"># 声明一个 Book 实例(instance)</span>
book1.name <span class="pl-c"># 访问该 book1 的 name 属性</span></pre></div>
<p>在分析前，我想先请求有编程经验的读者试着站在对编程一窍不通的普通人的角度去理解这段代码。这段代码
加上了注释后是很容易理解其意图的，即是我们用计算机创造了一本维特根斯坦写的书，并可以看到书名。我
个人觉得怪异的是为什么 new 一个抽象类就可以得到一本书呢，这在日常思维里有点费解，我们又不需要去因
为得去理解物质的运作原理而去创造原子，质子，光子等各种人类根本不可能直接看见的东西。我们需要的只
是一本看得见摸得着的书即可。为了避免误解和困扰，我再强调一次，"new 一个抽象类" 是一件很怪的事情。</p>
<p>而我们再来看看日常思维是如何表达这一意图的，"有一本书，书名是逻辑哲学论，作者是维特根斯坦"。在这
里，我们涉及到了一个名词, 叫"书", 一般情况下我们的脑海里会马上浮现出任何一本想到的书的样子或性质
，然后在其封面放上"逻辑哲学论"和"维特根斯坦"两处文字，并可能会细微地做各种相关的联想或猜测，这就
形成了一个完整的思维过程。</p>
<p>所以可以对比得到，我们注重的不是创造这一行为本身，而是强调通过一个思维过程，我们创建了关于一本书
的场景，而不是关注点过分落在了 Book 数据结构上面。</p>
<p>目前我想到设计的方案是这样的:</p>
<pre lang="human"><code>$Book: # 声明 Book 上下文概念
name: # 声明 name 属性, 数据类型未定
author: # 声明 author 属性, 数据类型未定
book1 = 1.Book(name="逻辑哲学论", author="维特根斯坦"). # 声明具体一本书的上下文
book1.name. # 访问该 book1 的 name 属性
</code></pre>
<p>和 Python 代码一样是分成两部分，上部分定义了 Book 上下文概念部分，有编程经验的人理解起来会相对来
说更偏向数据结构图，格式类似 <a href="http://en.wikipedia.org/wiki/YAML">YAML</a> 。下部分则开始描述行为，
和 Python 代码的不同点有两个，一个是用 "1." 代替了 "new ", 和自然语言里声明一本书语义一致。另一个
是末尾多了 "." ，这符号在 Python 等面向对象功能的编程语言里是没有的(并发函数式语言 Erlang 是有要
求语句以 "." 结尾的)。这是 Human 编程语言里 <strong>组合式</strong> 的意思，实际上是</p>
<pre lang="human"><code>new(1, Book(name="逻辑哲学论", author="维特根斯坦"))
</code></pre>
<p>的简略写法，在这两个参数组合在默认的情况下只有 new 函数是符合接受的。这里的提示信息有，该组合里有
两个元素，并且第一个是 1 数字, 第二个是一个上下文概念带着两个参数。在这样足够信息的情况下，new 函
数执行它, 并后返回一个 Book 上下文。</p>
<p>该上下文会绑定到 book1 变量，即目前剩下的语句是</p>
<pre lang="human"><code>book1 = result
</code></pre>
<p>其也是组合式,</p>
<pre lang="human"><code>book1.=.result.
</code></pre>
<p>展开的完整表达应该是</p>
<pre lang="human"><code>def(book1, "=", result)
</code></pre>
<p>即是把 result 值绑定到 book1 变量上。下一句也是用 "." 结尾的组合式来访问其属性的。</p>
<p>综上我们可以得知 Human 编程语言主要把代码分成了两部分，即数据和行为，所以 Context 数据定义是层级
式的，而函数行为是组合式的。组合式在本质上也是一个 Lisp 方言。</p>
<h3>
<a id="静态语言和动态语言-及其解决方案" class="anchor" href="#%E9%9D%99%E6%80%81%E8%AF%AD%E8%A8%80%E5%92%8C%E5%8A%A8%E6%80%81%E8%AF%AD%E8%A8%80-%E5%8F%8A%E5%85%B6%E8%A7%A3%E5%86%B3%E6%96%B9%E6%A1%88" aria-hidden="true"><span class="octicon octicon-link"></span></a>静态语言和动态语言 及其解决方案</h3>
<p>对于静态语言，我在理论和实践方面都很缺乏。以下只是一些零碎想法。</p>
<ol>
<li>Human语言虽然是动态语言，但是因为Context限制，所以鼓励静态化类型信息了。</li>
<li>Human某部分静态，即@static，就是真的是二进制静态语言的，同时就要求参数类型确定了。</li>
<li>human语言应该支持内部动静态的多进程化。并且支持内嵌其他动态语言解释器。</li>
<li>任何类型都是上下文，甚至字符串，整数。只是这些整数被编译为静态的而已。</li>
<li>加减乘除在C这个静态语言里是属于什么语法，除了函数以外。只是专门加的吗。因为在面向对象语言里是实现为方法的。</li>
<li>Human 里的静态就是静态的，即内部是黑盒子了，不管是不是已经编译为机器语言了。</li>
</ol>
<h3>
<a id="强类型和弱类型-及其解决方案方案" class="anchor" href="#%E5%BC%BA%E7%B1%BB%E5%9E%8B%E5%92%8C%E5%BC%B1%E7%B1%BB%E5%9E%8B-%E5%8F%8A%E5%85%B6%E8%A7%A3%E5%86%B3%E6%96%B9%E6%A1%88%E6%96%B9%E6%A1%88" aria-hidden="true"><span class="octicon octicon-link"></span></a>强类型和弱类型 及其解决方案方案</h3>
<p>我听说类型系统是个很专业的领域，以下也只是我的一些零碎刑法。</p>
<ol>
<li>因为你知道这个上下文用来做什么，所有你确定应该返回什么。多类型，或不确定类型（但知道这是我们已经定义过的，比如GSON），或者动态新建一个Context（？）。那所有上下文位置你应该都是可以找到的，如果存在但是找不到，那就新建一个了。</li>
<li>有上下文后，信息足够简明，是否可以做到对大部分进行类型推导了？！</li>
<li>不要for循环式的列表推导，而是用形容词列表依次处理。for遍历容易多层混淆。如果多个形容词，也即是循环类型的上下文，可以知道自己在第几层，并用类似_1，_2，的方式引用上层，或者指定引用哪个循环上下文。这样也有利于扁平式。</li>
<li>JavaScript里除了基本数据类型，就是对象和函数。而函数是带函数的对象，并且是原型继承。</li>
<li>写程序过程中得及时更新关系图，为单层声明，表示为JSON（以后可以作可视化分析）。如果是多对多，把关系类作为键。主要目的还是为了方便程序分析。类应该是大写。所有程序中用到的类必须在JSON里声明。这一切都是为了快速理解和清晰。这样一定意义上可以促进动态类型语言有静态化，便于类型推导。</li>
<li>基本数据类型是指可以通过01进行逻辑变换得到的。</li>
<li>基本类型就是维基百科标准名字，比如Integer(<strong>size</strong>),String（unicode)，Array（array,list),List,Stack ，Hash(linked,sorted)，Bool,，这样API不变，单还是可以用几个基本类型来思考。Array可以声明元素是否一个类型，声明了就不可以变了，反序列化会检查这些值（类名和<strong>type</strong>一致，其实这两个组合已经覆盖绝大部分情况了吧？）。 接上面，一个Context里，和Python类似，首先<strong>id</strong>，<strong>hash</strong>,<strong>type</strong>,等。</li>
<li>语言异常？类型检查我们一定程度上有了。todo</li>
<li>一个对象.context(函数名或属性名）返回那个context，属性可以认为是函数的直接返回，即类是函数，new之后直接返回就是基本类型数据。</li>
<li>用infer，表示某Hash是啥类型type，比如linked。</li>
<li>有些是符号，有些是对象（考虑类型）。</li>
<li>对具体命名的变量的每个操作，都记录引用，这样这个变量就不能轻易改变值或类型。</li>
<li>每个值都有其类型，类型有其范围(Range)，这个参考 Haskell。为了证明 dict = {"a":0\，"b":1\,</li>
<li>基本类型应该都可以转换。</li>
<li>[ ] 洗数据时的数据类型范围证明。17zuoye 数据各种异常太多啦，不过估计其他有一点历史的大一点的公司都是。</li>
<li>[ ] 就像英文单词首尾对识别度影响最大一样，在Human组合式里尽量利用首尾，这样尾部最好是数据类型，就像单词的词性一样。</li>
</ol>
<h3>
<a id="线性逻辑导致的软件复杂性-及其解决方案" class="anchor" href="#%E7%BA%BF%E6%80%A7%E9%80%BB%E8%BE%91%E5%AF%BC%E8%87%B4%E7%9A%84%E8%BD%AF%E4%BB%B6%E5%A4%8D%E6%9D%82%E6%80%A7-%E5%8F%8A%E5%85%B6%E8%A7%A3%E5%86%B3%E6%96%B9%E6%A1%88" aria-hidden="true"><span class="octicon octicon-link"></span></a>线性逻辑导致的软件复杂性 及其解决方案</h3>
<ol>
<li>上下文意味着没有继承，只有连接。递归是概念内部的，或者上下文内的，所以应该不会太复杂。</li>
<li>human语言里定义的所有上下文意味着显示了项目的复杂度的绝对性。</li>
<li>算法的难以理解，正是因为其复杂度太高了，所以更需要上下文编程。</li>
<li>69页。乔姆斯基，重视语法超过语义。对语法的重视（繁琐或矛盾的细节），导致程序的复杂性。所以上下文编程重点正是把重点放回语义的本源，并以此展开，这样就不会被逻辑控制。</li>
<li>组合对象技术，比如Rails里的6.weeks.ago。并不是方法链级调用，而是组合才发生这种可能性。这样避免复写6.weeks.ago。这是更强大的组合式思考上下文。最后多加一个点表示是句子，从而组合。 Rails里看着简单，实现复杂，记忆规则也复杂。组合就简单，符合人类思维，在组合里，小写自动解释symbol。</li>
<li>并没有简单和复杂之分，只是因为上下文。不过直觉和记忆是很神奇的。</li>
<li>人类可以存在，却无法解释实在。所以概念很复杂，上下文容易理解。</li>
<li>世界是复杂而又简单的，这种复调同像性在世界各个远近高低都是。小孩子觉得世界简单，大人觉得世界复杂，小孩子觉得大人复杂，大人觉得小孩子简单。显著区别的人可以划分为有限数个(比如生物类属)，类似的可以有无穷多(比如一到无穷)。但是这一切其实只是人类思维使然而已。</li>
<li>Human程序语言 导致的结果是程序在执行和语义上更适合被分层，便于调试，降低复杂度。</li>
<li>比如 Array API 的操作函数可能就十几二十几个，但是因为这些函数返回的还是 Array 就不觉 得其复杂了，只是觉得简单的多而已。举个例子，流水账易于理解，正是因为内在逻辑的扁平型， 而康德哲学难以理解，看了下一个段落，就忘了上一个段落，正是因为他指的概念之间及其错综复杂。</li>
<li>优化不意味着难以维护性，只是因为发觉了业务内在更多的复杂性。如果还是听觉，那就难以维护了。所以得用视觉。</li>
<li>大屏意味着视觉化，IDE也是，但是IDE太复杂？！或者不是真正编码想要的视觉化。</li>
<li>以有限性去推断无限性是不可能的，人类思维是无限和未知的（背后的机制），所以人工智能是不可能的。虽然一定程度上可能，但是规则还是太复杂了。即世界不是由相对论或某几个基础定律等所决定的。</li>
<li>人与人之间千差万别，除了人的复杂性外，用于理解区别的各种上下文也是关键，因为我们对于上下文是如此熟悉。</li>
<li>程序的复杂性证明了简单的东西组合后不一定简单。简单的只有直观的东西。</li>
<li>俊晨说的 luigi 极大地改善了代码复杂度。我现在认为是因为其中提取了内部逻辑的内省。递归只是函数级别的，效果还比不上类组织（以IO为基础）。</li>
<li>内省是解决软件复杂度的中心，所以在各个层次上思考why，what，how。</li>
<li>AppleScript的问题在于语言的复杂性，而没有明白程序的核心在于逻辑，而不是直接加入自然语言方式到程序语言里。正确方式是永</li>
<li>代码复杂度不能超过需求复杂度，需求复杂度即解释。</li>
<li>取消new关键字。完美的简单标准。越复杂越形式，helloworld就简单拉。1. one. another. 都是等价的。编程语言应该是简单的，很快被学会，这样可以释放精力给设计程序。语言应该尽量隐藏自己。</li>
<li>上下文对抗的正是复杂度。</li>
<li>看数据结构只是因为其比函数更简单和图形化，并有流转的依赖图。而函数则太复杂了不容易搞清楚。</li>
<li>世界的繁复杂多让人忘了世界的本质，比如如何高效学习。</li>
<li>对于复杂度而言，不是简单的位数，而是涉及元素的综合复杂度。比如100<em>100和101</em>101复杂度是不一样的。有人认为简单，但是在其个人而言，也是后者比前者复杂的。</li>
<li>C++ 用数组表示字符串，是想为了高效。而从抽象和解决复杂度角度看，也许编程语言提供分析复杂度比较好。</li>
<li>逻辑的本质在于约定，它的实现和执行在于人类发现了同样关系的等价实现。比如晶体管到电子（todo，用对的词）。至于本质为何只有与或非，也许就是在于比如阴阳之道，道教的一生二，二生三，都是类似的描述。但这并不是人类思维的本质，只是可被分解成的单元而已，本质还是人类思维的存在性在于寻找所谓的有意义性，一种信念。所以，也可以理解，日常生活中不太用复杂逻辑的，而是尽可能马上明白的意义。</li>
<li>企业级开发没有明白模块的本质，数据交换最好是单向的，多个相似系统协作会出人类思维本质的复杂性问题，一个死的，一个活的，这样就简单多了。所以多系统不要相互依赖，及时依赖，那也是函数级别的抽象依赖。</li>
</ol>
<h3>
<a id="领域特定语言-及其解决方案" class="anchor" href="#%E9%A2%86%E5%9F%9F%E7%89%B9%E5%AE%9A%E8%AF%AD%E8%A8%80-%E5%8F%8A%E5%85%B6%E8%A7%A3%E5%86%B3%E6%96%B9%E6%A1%88" aria-hidden="true"><span class="octicon octicon-link"></span></a>领域特定语言 及其解决方案</h3>
<h2>
<a id="解决软件内在复杂性是-human-的目标" class="anchor" href="#%E8%A7%A3%E5%86%B3%E8%BD%AF%E4%BB%B6%E5%86%85%E5%9C%A8%E5%A4%8D%E6%9D%82%E6%80%A7%E6%98%AF-human-%E7%9A%84%E7%9B%AE%E6%A0%87" aria-hidden="true"><span class="octicon octicon-link"></span></a>解决软件内在复杂性是 Human 的目标</h2>
<h3>
<a id="软件设计的定义" class="anchor" href="#%E8%BD%AF%E4%BB%B6%E8%AE%BE%E8%AE%A1%E7%9A%84%E5%AE%9A%E4%B9%89" aria-hidden="true"><span class="octicon octicon-link"></span></a>软件设计的定义</h3>
<p>软件设计是一项非常富有挑战性的智力活动，它专注于把大脑思维映射到多层次抽象的计算机逻辑体系里。</p>
<p>大脑的工作原理非常神秘，虽然我们已经大概知道大脑各个脑区的表象功用(有人类比当前的脑科学只是衡量了一下各个区域的温度而已
，然而具体如何工作还是所知
甚少，不得其法。从一个结果的，外在的，总结的，直观的，笼统的角度来说，软件设计从任何方面来说
应该尽量可以被大脑思维所理解，所直观，所利用，所改造，就像我们创造出的用来欣赏的艺术品，可口
的饭菜，舒适的房屋，快捷的交通等等一样。</p>
<p>计算机在本质上就是 过程 + 数据，用 CPU (central processing unit) 来操作 IO (input output) ，
也即是用布尔逻辑操作二进制数据。布尔逻辑包括基本的 与，或，非，再进而构建出 与非，或飞，异或
等复合操作(建议通过看 Wikipedia 上的 <a href="http://zh.wikipedia.org/wiki/%E9%80%BB%E8%BE%91%E9%97%A8">逻辑函数表示法</a>
得知其相互关系)，再进而构建出 集合交集，访问数组某索引的值，等常用数据结构的操作，最后进而构
建出万能的 函数 操作。数据在计算机体系里都表示为离散的 0 1 数字串，进而构建出 Boolean，
Integer，Float，Char 等基本数据结构，再进而构建出 String，List，Set，Dict 等高级数据结构，最
后构建出类继承系统，JSON，XML 等复杂业务数据结构。</p>
<h3>
<a id="概述软件复杂性的现象" class="anchor" href="#%E6%A6%82%E8%BF%B0%E8%BD%AF%E4%BB%B6%E5%A4%8D%E6%9D%82%E6%80%A7%E7%9A%84%E7%8E%B0%E8%B1%A1" aria-hidden="true"><span class="octicon octicon-link"></span></a>概述软件复杂性的现象</h3>
<p>正像其他智力活动一样，在确定好概要思路后，就可以投入到具体创作中。比如创作小说，在完成相对成
型的初版后，就开始不断润色细节，以使作品愈臻完美，最后达到该作品可以达到的最高成就。</p>
<p>然而软件的创造却自始自终都伴随着各种不完美，未考虑周全的各种 BUG ，因项目排期产生的各种 TODO ,
设计结构上的本质错误，常见的会对当前软件造成结构性更改的需求变动，等等。在不重要的小项目里，这
些缺点都是可以容忍的，而在动辄涉及到几十上百人的重要大项目里，重构是家常便饭，实在逼不得已，就
直接全部推倒重来，并在重新设计时吸取了经验教训，也会加入到下一版的核心设计思路里。在大项目的宏
观层面，会逐渐演变为 SOA (Service-oriented architecture) 架构，也即是模仿类比了现有的人类社会
结构组织。</p>
<h3>
<a id="分析软件复杂性的内在原因" class="anchor" href="#%E5%88%86%E6%9E%90%E8%BD%AF%E4%BB%B6%E5%A4%8D%E6%9D%82%E6%80%A7%E7%9A%84%E5%86%85%E5%9C%A8%E5%8E%9F%E5%9B%A0" aria-hidden="true"><span class="octicon octicon-link"></span></a>分析软件复杂性的内在原因</h3>
<p>如在 #软件设计的定义# 里所说，软件设计 涉及到两个方面，其一是大脑思维，其二是计算机逻辑体系,
两者关系是前者映射到后者。正如存在修补软件 BUG 这项活动，我们知道 大脑思维 是 远比 计算机逻辑
体系 丰富的，也即是对于同一事件，前者是包含着更多的信息的。所以我们也可以理解到，两者其实
是不等价的，前者比后者高级，前者需要被降格输出给后者。</p>
<p>所以导致的问题是如何挑选和组合 前者知晓的信息，把它们映射到 后者的逻辑里。而这里就涉及到美学
和逻辑这两个很宏大庞杂的领域，。</p>
<p>先打个比方, 用照相机给风景拍照，把三维的变成二维的，虽然我们知道照片指向着风景，但照片的信息
只是包含着某个三维时机里的某个二维角度，其他视觉信息都没了，当然视觉之外的其他信息自然也是不
存在照片里的。对于给风景照相这一活动而言，我们唯一可做的就是，花心思选择好构图和光线等，以求
得到一张美丽的风景照。即使是像照相这样相对绘画少了更多专业技巧性的专业，普通人拍的越没有专业
人士拍摄的精美并有更多的解读含义。</p>
<p>人人都知道美是什么，可是关于美的定义却常常说不出个确定的来。人人似乎都确信自己知道某个事物是
否美，而创造美却不是人人都可以的。面对软件这一首要以实用为要点的事物，接下来我会转而使用
<strong>上下文</strong> 这另一个词，即是从各个侧面去考察一个事物的各个方面是否美，是否好的。</p>
<p>逻辑其实是很复杂的，远比图像和故事形式等复杂，稍微有点软件设计经验的人都知道。这里我也举个小
例子用来展现逻辑可以多复杂，假如昨天是明天的话，那么今天就是星期五，请问今天是星期几？这个问
题我相信绝大部分人都不能在短时间里思考出结论来，因为我从周围人和互联网上观察来的现象即是如此。
我相信外国人也是如此，因为我在著名英文国际问答网站 Quora 上见过问题。我相信古人也是如此，我们
的身体就整体素质而言是强于古人的(即地球上更强盛的物种)，而头脑也不亚于古人，更何况现今普及的
义务教育。我相信后人也是如此，因为这是我设计 Human 编程语言的最核心思想, 上下文是有限的，具体
论述还得看完这整个草案了。最后稍微说下"今天是星期几"这个看上去只涉及到三个概念的简单问题处理
起来会超出预想的复杂度呢，是因为问题里得觉察出昨今明都可能有真假，而且相互缠绕在一起，假的今
天链接假的昨天，假的昨天链接真的明天，真的明天链接真的今天，每个都得仔细识别和确认，并理解成
一个上下文(这个星期几问题已经没法直观了，除非你记住答案)。所以三个概念已经很复杂了，成千上万
行的代码如何编写，升级，和维护呢，代码之间还有很复杂的逻辑关系(比有 BUG 更糟糕的是注释文档也
不可靠)。</p>
<p>我也是抱着类似的信念，挖掘和思索人类思维的本质，去设计一门对计算机语言用户来说易于思维和理解的编程语言。"易于思维"意味
着方便用户在具体业务和计算机多层次抽象之间的映射，同时也包含着创造。"易于理解"意味着方便某具
体项目的相关用户之间的协作，同时也包含着传递。</p>
<h2>
<a id="理解人类思维本质是解决软件复杂性的唯一方法" class="anchor" href="#%E7%90%86%E8%A7%A3%E4%BA%BA%E7%B1%BB%E6%80%9D%E7%BB%B4%E6%9C%AC%E8%B4%A8%E6%98%AF%E8%A7%A3%E5%86%B3%E8%BD%AF%E4%BB%B6%E5%A4%8D%E6%9D%82%E6%80%A7%E7%9A%84%E5%94%AF%E4%B8%80%E6%96%B9%E6%B3%95" aria-hidden="true"><span class="octicon octicon-link"></span></a>理解人类思维本质是解决软件复杂性的唯一方法</h2>
<h3>
<a id="思维是什么" class="anchor" href="#%E6%80%9D%E7%BB%B4%E6%98%AF%E4%BB%80%E4%B9%88" aria-hidden="true"><span class="octicon octicon-link"></span></a>思维是什么</h3>
<p>比给出美的定义更困难的事情是, "这个世界最不可理解的就是它竟然是可以理解的", 这句话是爱因斯坦
说的。这么说的时候，我们好像触碰到了用来思考感受创造美的思维(也可以说是灵魂，自我，注意力，之
类的概念, 或者是哲学家维特根斯坦所说的神秘之物)了，这个问题已经被众多哲学家和心理学家等各种家
所探讨，我也不知道是什么，在这篇草案里我也不准备尝试去解决这一问题，因为 Human 编程语言认为这
个问题是永远也没有答案的。</p>
<h3>
<a id="上下文-作为思维本源" class="anchor" href="#%E4%B8%8A%E4%B8%8B%E6%96%87-%E4%BD%9C%E4%B8%BA%E6%80%9D%E7%BB%B4%E6%9C%AC%E6%BA%90" aria-hidden="true"><span class="octicon octicon-link"></span></a>上下文 作为思维本源</h3>
<p>Human 编程语言最核心关注的是思维折射出来的 <strong>上下文</strong>，即一个感想，一段句子，一幅设计图，一组方
案，或者该组方案的好处，或者该组方案的坏处，或者该组方案的某一处细节。所以我们看到不同的事物
都可以抽象为一个上下文，甚至一个上下文可以解释为其他角度的上下文，也可以从内部剥离出一个新的
上下文。</p>
<h3>
<a id="上下文-引发出的事实" class="anchor" href="#%E4%B8%8A%E4%B8%8B%E6%96%87-%E5%BC%95%E5%8F%91%E5%87%BA%E7%9A%84%E4%BA%8B%E5%AE%9E" aria-hidden="true"><span class="octicon octicon-link"></span></a>上下文 引发出的事实</h3>
<ol>
<li>有限性</li>
<li>外部二八原则, 从使用量上</li>
<li>内部对称性 ， 1, 2</li>
<li>易变性</li>
</ol>
<h3>
<a id="上下文" class="anchor" href="#%E4%B8%8A%E4%B8%8B%E6%96%87" aria-hidden="true"><span class="octicon octicon-link"></span></a>上下文</h3>
<ol>
<li>上下文是人类思维的特征，比如日常交流里</li>
<li>上下文的例子随处可见，日常交流，文学作品, 既是优点，也是缺点。美驱动着上下文。 编程语言里。 我认为这是</li>
<li>上下文的定义取决于一般人类思维能力。</li>
<li>人们通过时间性联系在一起，即所谓时过境迁。人以群分通过上下文或语境相似联系在一起。家族的血统通过人的向死而生延续着。</li>
<li>人不能同时思考两件事情意味着上下文。</li>
<li>写完代码，但是一般来说一定不完全正确，还得调试，这就是人类上下文的局限。</li>
<li>编程语言设计核心要义是以相对上下文为中心，辅助以各个概念层次。应该不是基于机器学习的统计来，而是显示的固定规定。或者当前项目自身，或者经验统计。</li>
<li>识别不是自上而下，或者自下而上，而是整体，整体意味着注意力，即上下文。视觉从视野里分离出主体的汽车。</li>
<li><p>事件编程是手工指定异步IO，其实应该可以自动的。过程式是短期记忆。面向对象是带状态转移的过程式编程。函数式编程加快上下文切换（curry），确定性。</p></li>
<li><p>因为javascript只有一个CPU，所有代码是同步的，而IO不同步。假如js多进程，多线程，问题就多了，得函数式编程了。现实世界却没有问题，真奇怪呀！所以问题就出现在人类大脑的单CPU性，上下文切换乱了。现实世界对我们来说真的是个谜啊。</p></li>
<li><p>一切皆上下文。Human 编程语言也是一个上下文。</p></li>
<li><p>给一个上下文理解，而不是一堆Object。上下文就是解释。</p></li>
<li><p>上下文不是思维的某种形式，而是思维的本质。其驱动者是自由意志。</p></li>
<li><p>上下文，类，对象。复用算是什么？</p></li>
<li><p>区分只是在上下文内部，上下文本来就是独一无二的，否则没必要创建一个新的上下文。</p></li>
<li><p>上下文本身是个上下文，它也理解不了上下文以外的东西，所有上下文理论是自证的。</p></li>
<li><p>举例ActiveRecord的类定义里有scheme和方法等，两者可以分开为两个上下文，但是可以像Ruby传统里可以直接调用，或者另外一个关键字（多个平行上下文就看顺序排列优先级）。得有关键字来做平行定义，说上下文a平行于上下文b。</p></li>
<li><p>VIM分屏就是展现当前编程人员涉及到的上下文。</p></li>
<li><p>《重构》里推荐一点点重构正是“人类上下文局限”的体现</p></li>
<li><p>Ruby的面向对象，上下文，括号省略，block等 很适合DSL。这个符合DSL的阅读习惯。</p></li>
<li><p>没有上下文限制导致概念间的误解，比如函数调用开销大。</p></li>
<li><p>避免继承，鼓励组合。所以Ruby的mixin module在这里变为.<strong>type</strong>和.type("feature")。相当于用形容词实现。实现多个上下文一起思考，也好像变成了易于理解的自然语言描述。相当于存储引擎改了，可是我们就直接创建MySQL表使用，约定大于配置。这样不是一颗树继承（不鼓励太深继承），而是可以向前向后联结。</p></li>
<li><p>顿悟是上下文之间贯通，形成直觉的过程。</p></li>
<li><p>懂很多和未知原理的上下文是一件刻苦的事，所以初中对前端blocks式架构超出经验范围有点诧异，但是因为能work和并非完全不可懂而接受。另外jQuery实际上是一套声明式DSL，已经无缝融入JavaScript了，所以用户接受了。</p></li>
<li><p>上下文是人类理解思维的，所以是一直不可完备的，上帝的才是完备的。</p></li>
<li><p>概念不是上下文，而是体系，是上下文的一个直观。正想爱因斯坦的相对论公式，每一个都需要更多的解释。其他公式也是如此。</p></li>
<li><p>文学化编程文档注释多，代码被缩进夹在其中，其实就是上下文的体现。</p></li>
<li><p>每个上下文都得至少一个注释，即使是个空格。也即是“文学编程”。</p></li>
<li><p>美体现在内聚性，这和上下文相辅相成，包括不同原子或上下文摆放体现的美感和内在逻辑。</p></li>
<li><p>长尾只是因为上下文。包括二八定律。正态分布。字符频率定理。等等。</p></li>
<li><p>编程就是思考，思考就是上下文。</p></li>
<li><p>从效果出发，把次要元素去除，类似计算机不同层次的IO，从而得出定律，这全是上下文的功劳。</p></li>
<li><p>从上下文走到上下文，别人验收软件另一个上下文。从耶鲁《死亡》想到听觉作为说服的艺术。</p></li>
<li><p>git commit 细粒度的上下文思想。</p></li>
<li><p>领域无法解释不同领域之间类比的现实。所以上下文更确切。</p></li>
<li><p>解释就是经验的上下文。</p></li>
<li><p>公司架构和部门和职位即是上下文。</p></li>
<li><p>好的幻灯片完美的展现了谈话的重点和上下文。</p></li>
<li><p>在没写完代码前，认为任务简单，正是因为上下文机制。即使明白者，也认为多花时间别人和自己就会理解，实际上都高估了。可是这附加和隐蔽的上下文藏在哪里，可否通过逻辑等手段推断出呢。答案是不能，因为上下文是人类理解的形式，形式为直观和超逻辑和美感等所创造和推动。上下文内在才是逻辑的。</p></li>
<li><p>通俗讲解即是把专业术语的上下文放入接受者熟悉的上下文（通常是日常经验），在一个上下文里，置换一个（或者二个）即可。这样别人就理解了。</p></li>
<li><p>生命才有上下文，即需要一个head。而无生命体不需要。没有思想，就没有重点，缺乏凝聚的重点，比如岩石等。</p></li>
<li><p>额外性意味着杂质，意外，无意义，和主体上下文的关系很微妙。</p></li>
<li><p>GC和上下文结合在一起，可以实现局部回收。每一个上下文需要给出一个自足语义。</p></li>
<li><p>快速编写程序应该属于DSL，否则应该构建完备上下文架构。</p></li>
<li><p>长时记忆是一种上下文的记忆。</p></li>
<li><p>概率论是上下文体现出的另一个角度。这个世界有本质，在人类的上下文看来体现为概率。也许公式就是概率的某种极致。</p></li>
<li><p>限制是对堕落的制衡，对内心的平衡，上下文思考的辅助。</p></li>
<li><p>程序都应该知道当前在哪个上下文，比如函数内部也应该知道。这样比如递归就不需要还是本来名字了。当然函数内部的栈就对一个对当前函数引用了。</p></li>
<li><p>REST的优势其实就是上下文吗，接口不会一团乱。</p></li>
<li><p>所有词法是静态的，那该上下文就是静态的。</p></li>
<li><p>人类语言肯定不是机器语言，因为隐含了太多经验（上下文）。</p></li>
<li><p>程序等价 人类思维等价</p></li>
<li><p>对于程序，不是部分组成整体，而是整体拥有部分。即整体大于合成的部分，其实任何事物都是这样，因为上下文总是可以展开的，待发现的。这说明了人类思维的局限和特点。</p></li>
<li><p>整体论或还原论本质就是人类思维有限上下文体现的两面。一面是分解，一面是意义。上下文就是时间的来源，时间联系了所有人的思维。</p></li>
<li><p>谈话有时比文档架构图表更好懂的原因是有个上下文清理。</p></li>
<li><p>时间让上下文成为可能，也让叙述变得理解。</p></li>
<li><p>因为生命原理是上下文，那么生命的认识原理也是上下文。</p></li>
<li><p>函数不属于对象，而只有当进入某行为上下文后才有所行动。</p></li>
<li><p>写文章用成语是加入故事型上下文，加深理解的方式。比如高中时“结绳记事”成语润色了文章。</p></li>
<li><p>进入另一个上下文机制，比如对象序列化，也是一种 as 模式。就好像一列座位用List的API。</p></li>
<li><p>面向对象里会在函数里绑定一个星型模式的对象上下文。</p></li>
<li><p>加 <a href="https://github.com/safe" class="user-mention">@safe</a> 装饰器，把一个上下文包裹起来。然后要求该上下文里牵扯到的其他众多上下文也是 safe 的。有些对象虽然丰富，牵扯</p></li>
<li><p>提取重点这种上下文手段非常重要。</p></li>
<li><p>在还原论里，会导致结论就是原因。比如上下文导致了上下文。</p></li>
<li><p>等号会返回值的上下文，并可以体现出具体值。</p></li>
<li><p>刘慈欣说的水滴在小尺度上也无懈可击，只是因为人类上下文理解还没到那个程度上而已。所以应该还是上下文文明。而不是上帝文明（另外的）</p></li>
<li><p>一般意义的函数和上下文概念可以玩出闭包和惰性求值等高级玩意。</p></li>
<li><p>数据没有上下文，因为它们待思维去解释。而代码就是思维，所以有上下文数量限制。</p></li>
<li><p>限制上下文七个实际上是强迫用户做减法和归类。</p></li>
<li><p>不是说世界是由上下文组织的，而是人类认识是由上下文组织的。</p></li>
</ol>
<h3>
<a id="思维有什么用" class="anchor" href="#%E6%80%9D%E7%BB%B4%E6%9C%89%E4%BB%80%E4%B9%88%E7%94%A8" aria-hidden="true"><span class="octicon octicon-link"></span></a>思维有什么用?</h3>
<p>思维给我们带来了两件东西，其一是上下文，其二是美。</p>
<p>思维的局限性导致了多学科的出现，也即是人类社会的繁荣。</p>
<ul>
<li>人类思维用语言来表达，因此语言体现了人类思维。编程中的例子可见 "Context"。</li>
</ul>
<h3>
<a id="视觉" class="anchor" href="#%E8%A7%86%E8%A7%89" aria-hidden="true"><span class="octicon octicon-link"></span></a>视觉</h3>
<ol>
<li><p>视觉是美的，原始的，自然区分上下文的。</p></li>
<li><p>人眼如何把大千世界尽收其中？人眼分辨率？ -> 视觉最靠近大脑，会被大脑自动分辨为有意义的上下文。</p></li>
<li><p>单词由字母组成，可是阅读时就忽略了，而着重于意义。所有视觉有自动识别的肌肉上的特征。</p></li>
<li><p>编程让造物主从对象自身设计，七个器官，五个手指。而使用量和效果也是依据二八法则，比如人类依赖视觉远多于听觉触觉嗅觉等。大拇指和食指的组合占据了大部分。</p></li>
<li><p>眼睛视觉和思维视觉，孰先孰后。</p></li>
<li><p>视觉，听觉，触觉，嗅觉，味觉，空间感，思维自我。一共七个。短时记忆为七个。</p></li>
<li><p>长时记忆是视觉，短期记忆是听觉（156页）。我和女朋友出来，记得路上发生事情图景的前后次序和细节，至于听觉，只有特别印象的才有，比如服务员问我点了什么冰激凌。想想昨天和连华俊晨聊了什么，只有零星的整理概念，比如音乐爱好，点菜细节。短期记忆是听觉可能就是因为我们生命的时间性。 所有难以维护和理解的代码是听觉记忆。好的是视觉记忆。之前我把编程比拟为绘画即是如此。</p></li>
<li><p>可阅读的文字是视觉和听觉的结合，短期记忆和长期记忆的结合，考验人脑思维组织的技艺。</p></li>
<li><p>连华说我的内存小，理解周报告家长端。因为我和别人沟通经验不足，更多是视觉思维。别人是听觉思维。所以在长时记忆里我胜出。</p></li>
<li><p>符号编码连接视觉和听觉。</p></li>
<li><p>建议编程都切换到更有利的视觉模式。</p></li>
<li><p>而创造力和视觉听觉模式无关，我还没有想。创造力是在一定时间里专注才能有的。</p></li>
<li><p>听觉和视觉唯一可以相互转化的只有符号。</p></li>
<li><p>视觉有模式（思维会从中找模式），而头脑里的一堆概念无法找模式，所以有数学家用图像思考。</p></li>
<li><p>human虚拟机执行和Luigi类似，有向无环图。当然也一样可以做视觉化展现，无论是当前项目还是整个VM。其实就是命名空间。</p></li>
<li><p>思考快速眨眼，可能是来自远古需要细察周遭环境而进化出的特征，依赖于视觉模式。或者思考时看着空白的天花板。</p></li>
<li><p>爱因斯坦文集一。567页。《关于数学领域的创造心理》。他用视觉和动觉，用肌肉。语词出现时才纯粹是听觉的。所以编程和敲击键盘一起才变成听觉的，这个技巧很难把握。编程提前思考意味着视觉更多。</p></li>
<li><p>视觉编程应具备符号DSL的能力，譬如函数式语法，所以符号在可视化上很关键。matz最近设计的streems即是。</p></li>
<li><p>肌肉记忆，视觉记忆，听见记忆，三者在思维中混淆。常见于游戏中。</p></li>
<li><p>视觉站在思想前方。</p></li>
<li><p>梦的无声即是证明大脑以视觉为主。补: 换到梦里去了。</p></li>
<li><p>现实世界是美好的，眼睛耳朵即是。而大脑唯有由美指引，才能领略世界本质。所以大脑思考可以尽量降级为视觉，而非听觉，以便于沟通。</p></li>
<li><p>耳朵不可以关闭的原因是鼻子，触觉等更低级的也无法关闭。只有视觉的眼睛才可以关闭，因为其对大脑思考影响最大。人的大脑被封闭在脑壳里</p></li>
<li><p>甲让乙计算五加七等于几，乙先是耳朵听到，传入到大脑里，在大脑里用视觉浮现出六和七两个符号，然后根据肌肉记忆，计算出是十二这个数字，最后用嘴巴说出十二这个数字。</p></li>
<li><p>视觉影响大脑思考，故用下一层的听觉来全方位地作为大脑思考和沟通的顺序。</p></li>
<li><p>人在大脑里对名词有想像视觉，是因为有经验，比如马，或者组合出来的龙。但是却不能想像灵魂，因为没有视觉经验。或者“有”这个词也是不能视觉的。</p></li>
</ol>
<h3>
<a id="软件工程" class="anchor" href="#%E8%BD%AF%E4%BB%B6%E5%B7%A5%E7%A8%8B" aria-hidden="true"><span class="octicon octicon-link"></span></a>软件工程</h3>
<p>并发好像和语言无关哦。</p>
<p>lisp遵循human是否可以，还得学会lisp再说。</p>
<p>闭包的本质是把数据（类）的地位让与函数，，也是how让位与what（how必须通过数据改变来体现，而what只是表达了一种声明式。</p>
<p>一切都是逻辑，数据是，函数是，区别是数据是被动的，函数是主动的。另外，函数因为数据而显示其自身，当然就计算机表示而言，他们是均等的。</p>
<p>代码不应该拖累讲解速度。即脱离代码给别人解答具体相关问题的速度，结合代码讲应该更快些，而目标效果就是对方可以维护这相关代码。</p>
<p>敏捷等方法论，程序语言之争，项目工程管理，都已经成为宗教。而问题的本质就是人类思维，我觉得还是和人类思维本事死磕更好些，与自己和别人死磕。所以有句话说，问题的本质还是人。</p>
<p>因为计算机完全可以被人所控制，所以其中的“时间”也是被控制的。但是当人类面对其他未知事物，比如外太空，那必然得先抱着敬畏态度，并随时准备接受颠覆世界观的可能性。</p>
<p>函数（即过程）和类可以合并为一个概念，这点参考JavaScript。</p>
<p>可选。类也有版本的概念。包括其中数据和行为。</p>
<p>软件工程毕竟还是一个完全在人类日常经验范围内的。</p>
<p>UML 为什么失败？！<a href="http://www.cnblogs.com/shuhari/archive/2009/07/01/uml_is_failure.html">http://www.cnblogs.com/shuhari/archive/2009/07/01/uml_is_failure.html</a></p>
<p>编程语言依赖的作业环境应该不依赖于 编辑器或IDE。</p>
<p>互联网快速开发实现是以牺牲远见为代价的。</p>
<p>链接后的语法树雷同于Human编程语言，但过程和结果还是值得我研究。</p>
<p>explain编程语言。编程就是教一个傻子做事，不断的解释。</p>
<p>DSL的伟大之处就是在于单一职责，局部性，以及线性故事性。</p>
<p>对计算机来说，talk is explain.</p>
<p>human翻译成Python代码，就像CoffeeScript翻译成JavaScript一样。但是得注意是否可以一一映射，而且Python是否优点够齐全。JavaScript主要是事件驱动太强不合适。</p>
<p>talk is cheap，show me the code。意味着核心思想可以剥离，最终结构的生成以及平衡等都得益于功力。</p>
<p>linus 指的数据结构及其关联比算法重要其实是针对 数据持久化的项目来说的，也许不完全是。</p>
<p>Linus 说，计算机科学和物理一样，都是在一个非常基础的层面，探讨整个学科的运作原理。66页。</p>
<p>在有经验的前提下，审美是首位的，敏捷和解决方法的出现其次。和晓光讨论JsonUtils.unicode_dump有感。</p>
<p>我始终觉得不必完全在意别人的看法，只要自己觉得可以相信自己能领导自己就可以了，而不是把全盘把自己交给整个社会体系。</p>
<p>群体智慧不是投票，而是每个人都有自己的主见。</p>
<p>在项目的不同编程阶段，人是会遗忘的。对概念和概念关系加以拓展和进化。这也类似于众包的维基百科。</p>
<p>我有这么多开源项目，以精简复用的形式表达。</p>
<p>对一个编程低手说，即使你的程序达不到优美，但至少应该清晰。虽然清晰和优美同样难。Java是否完成这一任务呢，没有，在犯错上强制了点而已。</p>
<p>Java的强制异常检查错的地方在于不能把它和其他东西分离开来，这样是一种混乱和干扰。所以我更期待可以在任何层次和区域分离的模式匹配。</p>
<p>前端在于它的被限制性，重置性。按业务场景（人类交互）分离是很正常的。前端更像现实世界，服务器端只有通过各种接口机制更多，即数据。很少直接去操作服务器内部细节。从业务整体角度看，它只处理了前端部分。静态页面由后端处理逻辑，单页应用则承担半壁江山（中学题库）。</p>
<p>被项目后来者理解，代码必须转为长时记忆模式。</p>
<p>CPS和human编程语言。human强制数量，可能得引入CPS。</p>
<p>函数式里用CPS递归方式实现for循环，避免变量赋值或重写。</p>
<p>代码最好具有不细看也知道做什么用的特点，适当的注释和布局。</p>
<p>和一般编程语言有一样的Object基类，但是名字换成Context。属性可以任意多，但是行为最多七个。考虑一下原型继承。</p>
<p>声明式的SQL是一套限制型的逻辑范式。</p>
<p>二分查找的递归是生成新列表，迭代是范围值缩小。</p>
<p>human的包机制和python的import语句应该差不多，但是托管机制还是和ruby和node类似吧。</p>
<p>Context也是可以run的。是否参考Python用两下划线表示内部呢。这样就支持函数式编程了。</p>
<p>Python里的关键字class和lambda,在这边都用context表示。没有Context，所有默认继承于此。或者和Python一样有没object都可以，但是会少了object属性们。如果是Ruby，所有都是Object，加上面向对象，那就可以方便进行5.week.ago这种链式调用了。</p>
<p>python的<strong>slots</strong>设计如何？</p>
<p><strong>type</strong>里包含了默认属性，所以这个是在另一个context里定义的，没有就用默认的。</p>
<p><strong>type</strong>赋值的是String，比如“list”。</p>
<p>一个Context可以有多种<strong>type</strong>，这多个types的数据是相互映射的（说错了，大小整数就不可以，只能说一部分可以转到另一部分而不会发生改变），既可以一一转化，比如最简单的是Array和List和Stack。但是它们之间函数个数和名字可以不同。</p>
<p>自定义类比如表示一个长方形，宽和高，惰性属性面积。</p>
<p>函数和数据如何转换？Python有property把函数转为属性。</p>
<p>Python做错了，点就表示调用执行了，如果看定义，比如通过<strong>dict</strong>看本来是什么，或者从类里面看。我刚从Ruby转过来接触Python，对方法必须加括号才能执行表示不适应。</p>
<p>动态属性如何实现？Ruby里有method_missing。直接定义一个<strong>missing</strong>属性函数。关键是这个missing也得由context实现才能统一概念。</p>
<p><strong>type</strong>就多了一个概念啊，在继承时无法指定哪种Array。todo</p>
<p>每个context有一个HTTP URL地址。</p>
<p>Ruby语言的缺陷，缺乏命名空间，这点Python好。但是Python的类和实例没用大小写区分也是遗憾，当然一个类new之后也可以返回类。</p>
<p>异常的本质是，是可以预见的吗？！</p>
<p>和人类社会和个体一样，一个事面向一个主体。虚拟机审视代码逻辑依赖启动，如果没有并发，就等价于传统单进程执行。执行流程可以被审视，在human里，和Hadoop等分布式一样，可以把一些动态context注册，即是它们会出错，有栈。而一些很固定的，它们不会出错，出错也是它们可以预见的。会出错的就得注册。</p>
<p>state monad</p>
<p>for循环在七个限制里结构优先。</p>
<p>json键值并列赋值就是扁平化，但是也要考虑内部的上下依赖。</p>
<p>遗忘测试。在三个月后看代码。</p>
<p>"类“正是一种模式识别或匹配。</p>
<p>形容词用Ruby的symbol表示，其实也是类似于协议，但是也包含实现。</p>
<p>限制性的明确解释。</p>
<p>可以多于七个，但是必须使用序数注解。</p>
<p>为什么可以修改IO而不能修改CPU呢，因为修改了CPU即是把CPU当作IO了。</p>
<p>@ 既是 doc，也是 decorator。</p>
<p>Ruby里的module加上限制后其实就等价于human里的形容词。</p>
<p>在human里体现丢弃的概念，即封装成某一个层次，机器码，字节码，程序代码，等。但是现在语言只有程序代码一个层次，否则就得多语言混用，比如Ruby的C扩展。 其实不需要这么多出错栈，只要对应的局部即可。</p>
<p>loop实例化，并变成闭包。while同。</p>
<p>每个context里最多包含7个context，除非序数编号。loop，while都是context。</p>
<p>形容词变成symbol，这样不必引用类了。在参数传入时限制行为。</p>
<p>代码排列应该尽量交给编程语言，可以自动检测的。</p>
<p>组合 前面其实也需要.的，但是如果是语句开始，一般就省略了。或者是homework..day_limit.days.ago. 。找个更好的例子TODO。</p>
<p>不要关键字new，而是 book1 = 1.Book(name:圣经)。这样更符合日常直观，而采用的是组合模式。</p>
<p>for 循环等 其中的变量名必须以数字结尾。</p>
<p>于是类名是否支持复数形式呢，我认为应该在 组合 这一层次上解决，纳入标准库。复数其实不强制。</p>
<p>取消继承，和Haskell一样（待确认）。最初随意指定一个对象就是Nil，即从虚无中来。当添加一些东西后，比如组合，就不再是Nil了。</p>
<p>@表示装饰，$表示资产。</p>
<p>软件架构正是慢速思考的体现，思索每个角落，灵感出一个方案。</p>
<p>程序员三大美德之一暴躁是因为设计程序需要集中精力，外人不能中途打扰。</p>
<p>on关键字替换,loop,for,while 等。两个for循环，第一层两个变量，第二尝遍历第一层第二个变量，并和第一层第一个变量相乘，得到一个总数。</p>
<p>如果变量仅在一处作用域使用，推荐放入该作用于。或者该变量是外部某一对象的属性。</p>
<p>字面量均通过.结束来返回具体对象，字面量仅仅作为概念，但不是对象。这样通过组合就可以了。</p>
<p>method作为公用函数，而len才是Array方法或属性。如果是类似Python的<strong>dict</strong>也应该用公共函数取。可理解可读可划分永远是第一位的。</p>
<p>首先明白在管理依赖这个业务里，编程比UI强大，UI是由编程API构建出来的。所以两者不矛盾，也不存在难维护的问题，唯一区别是UI比纯粹编程多了可视化操作的功能。</p>
<p>调研 DHH 是如何写 Rails 的。</p>
<p>框架是从业务中逐渐抽取出来的。即是不能脱离具体业务，就直接写出一个能通用和完美解决问题的方案。一般而言，软件架构师是在完成具体项目时，就顺手完成了一个框架。或者换一种方式，框架的测试（包含测试业务案例）也是跟着业务开发的。 所以软件架构师带头写代码是必须的。另外还有几种架构师，技术架构师是对一种以上的技术体系非常熟悉，而且能和业务结合起来，这可能不太写代码。运维架构师，项目经理就不说了。</p>
<p>任何框架（包括编程语言）都有至少一种核心理念，且是内省的，即是指导的原则，也是逻辑结构。</p>
<p>鼓励使用组合多过函数属性，组合其实在二元函数上又多了一层内省结构。</p>
<p>函数只是代码的数据而已。而且应该是有能力向外部提供各种细节。只是数据的上升而已。</p>
<p>context是value\，order list 等。</p>
<p>私有方法，抽象类，全都离具体业务太远了。只是为了表达结构而存在的。</p>
<p>虚拟核，虚拟进程，用消息命令，黑盒，模仿人类指令。</p>
<p>函数或方法在本质上就是两两组合的形式，其实在自然语言里更多才合适，也容易被思维理解和操作。</p>
<p>对称性在语法上的体现。_.序号等。</p>
<p>一边是组合式，另一边是函数组合，这样对称性。</p>
<p>8 / 2 其实是 8./.2. 的组合式的简略写法。即 / 隐含了 ./. . 。这样不要面向对象，而是 [8 , /, 2] 共同组成了表达式，缺一不可, / 后面必须跟着一个数字，而不是歪着理解为 / 是 8 的方法，2 是参数，太费解了。</p>
<p>(3 / 2) * 3 这种就得强制加括号了，因为没有 / * 这样的模式，除非自己定义。所以展开是 (3./.2.).*.3.</p>
<p>一个是 Context \，相当于通常的 class。另一个是 Bundle，相当于通常的 module。Bundle 即是函</p>
<p>在组合式里，加个括号表示引用的是对象。可是这样参数如何传，还是前面加个一撇呢。</p>
<p>一个变量既有代码结构，也有求值。</p>
<p>函数的本质就是改变输入为输出吗？那函数式和命令式本质区别在？</p>
<p>除非性能，否则正常的直接推理相关业务逻辑即可。</p>
<p>类可以多个别名，这样就支持2.Books 返回一个列表了。</p>
<p>用 =: 表示依赖变化 求值吧。这样可以表示for循环中值改变。</p>
<p>类方法或者静态方法，用组合式就足够了。</p>
<p>human语言不是继承模式的。而是组合模式。因虽然是像Ruby 一样include module \，但是其要求符合默认不超过</p>
<p>对象不仅仅是值，它们会体现为值。也即是人们看重的价值。</p>
<p>函数是数据的运行模式而已。静态语言对于这个限制更大，因而看上去更底层。</p>
<p>根据 <a href="https://github.com/safe" class="user-mention">@safe</a> ，我们就可以把某些上下文编译（优化）为纯二进制执行文件了。</p>
<p>函数应该是可以序列化的，即使牺牲了空间。可以和js类似，这样不用管外部变量。</p>
<p>如果要实现可改变的，就用另外形式的。这时值其实算是求值的，并且应该携带相关信息。比如：changeable Item :=</p>
<p>erlang的函数多版本其实是符合自然语言理解方式的。比如登陆，可以只有用户名，可是还得兼容用其他登陆，比如加年龄地区以区分重名</p>
<p>_和.这两个符号是必须在语法设计时融入的，因为它们足够低调。</p>
<p>不管是面向对象的对象加函数属性，还是函数式组合，都逃不出二元论基础，而缺乏组合式。</p>
<p>编程关键，concept\，aspect。</p>
<p>赋值用 := 表示，如果里面变量是可变，就加个前面一撇。类似于Haskell和Lisp。不过还是觉得所有变量的赋值都是一经赋值，</p>
<p>Human 里尽量分离数据和函数过程。</p>
<p>一个程序运行起来后，不同服务应该是消息沟通, 类似 Erlang。</p>
<p>鼓励使用组合多过函数属性，组合其实在二元函数上又多了一层内省结构。</p>
<p>如果一个人会看菜谱做可口的饭菜，那么TA就应该可以学会一定程度的编程，分析，步骤，逻辑，优先级，主次，等等。</p>
<p>. 和 空格其实算是等价吧。</p>
<p>Human 语言的hello world 版本。 print."Hello world.\n". 内置组合。</p>
<p>程序内部尽可能分离。系统层面的模块化，像SOA。</p>
<p>像 Lisp 括号来括号去简直是反人类的。</p>
<p>谁能一下子说清 C 语言里运算符优先级。</p>
<p>=/= 这个符号作为模式匹配不错。其实根据组合里的是字符串，就可以自定符号啦，所以各种颜文字，-_- 什么的。</p>
<p>我建议学过编程和想了解编程的人都看一看。</p>
<p>使用组合式后，原来的对象只有数据了，函数剥离到组合式去了，并通过输入输出绑定。</p>
<p>Context是全局共享的，如果冲突，可以使用 Model(ns=other)解决。另外代码是必须放在隔离的Package 里运行的。如果是单文件等没有包名情况，则会随机一个，类似main。</p>
<p>函数也是数据啊，也可以被序列化。至于绑定的闭包值，和实际函数代码，当然都放进去啦。</p>
<p>上下文里也可以有函数属性，默认上下文事当前文件，文件命会作为包名，和java和python类似。使用某些函数组合式，导入即可。遇到组合赋值，函数就自己吸附上去。当然，上下文自己也可以覆写引用，即是有作用域。</p>
<p>[ ] 赋值变量其实就是创造，就是新上下文。</p>
<p>[ ] 组合式其实就是省略了函数名，通过参数确认唯一函数了而已。当然，也可以是有函数名的，这就相当于完全展开版了。对，省略写法而已。</p>
<p>[ ] 组合式其实也和 Lisp 的括号也非常像。</p>
<p>[ ] 代码编排的规则限制和REPL是两回事。</p>
<p>[ ] 数据表现为分类结构，函数表现为依赖结构。</p>
<p>[ ] 函数也是一个可持久化上下文，里面有source code。</p>
<p>[ ] 并不取消类和对象，而是取消 类不能new。以及类方法等。</p>
<p>[ ] 函数的序列化方案和问题。</p>
<p>[ ] 讲解为什么不要修改烂代码，直接重写它。</p>
<p>[ ] for循环也和loop一样，支持break等关键字。也是YAML，除了关键字键break等外，也只是函数，以可以抽象组合，同时也把for循环变成可操作对象。</p>
<p>[ ] 代码运行正确结果只是生存，代码写的容易理解才是生活。</p>
<p>[ ] 如果loop和for是结构的话，其中几个函数属性，那么就很容易包装和重写了。</p>
<p>[ ] 最完美的语言，完全为表达服务。数据结构声明里也有$表示递归结构。</p>
<p>[ ] human 第一个实现版本先为 js 版本，用以解决 javascript 里的问题，这样用户最多。</p>
<p>[ ] 禁止拷贝代码可以这样做。拷贝代码一般是函数，即一个函数库，（虽然在 JavaScript 里函数套函数的），那么只要函数足够大，比如十多行，那就检测其不要复制，推荐其封装。</p>
<p>[ ] 函数内容是作为延迟执行存在的，而其内容是会关联到外部的，所以也是一种惰性依赖声明。</p>
<p>[ ] 既然代码是逻辑的，CPU也很快，为什么就不可以很快的分析。</p>
<p>[ ] 憎恶过多的缩写</p>
<p>[ ] 变量加上1,2,3,4,..，正是我们在自然语言里表达层次结构的做法。</p>
<p>[ ] $= <code>a +</code>b + `c ，就是 hold，把任务声明后交给别人了。</p>
<p>[ ] 程序的作用块是可以脱离的，即一个文件里的个别语法错误不会影响到真正执行，除非调用。这种方式的实现依赖于最小作用域。</p>
<p>[ ] C和Lisp相当于原理，可是却解释不了人类语言，人类思想，大概就是这个上下文类比。</p>
<p>[ ] 依赖求值意味着要被循环或递归驱动，那么human如何表达循环或递归呢？</p>
<p>[ ] 继承劣于组合的原因是带来了人类不擅长的深度维度。</p>
<p>[ ] 参数代表函数，正是相当于分离出隐含的上下文。</p>
<p>[ ] @表示实体，即在YAML类定义时加下就可以了。如果link或内含array什么符号表示呢。</p>
<p>[ ] 组合式和函数定义分开，有利于用户去构建DSL。</p>
<p>可以两格缩进，也可以四格缩进，缩进只在 <strong>当前文件</strong> 有效，取决于文件的前面部分是用的几格缩进。</p>
<p>"##" 之下缩进的块是文档</p>
<p>"#" 表示文档，"$" 表示数据结构, "@" 表示函数, "%" 表示组合模式。</p>
<p>数据结构的操作，还是尽量和函数分开。其实这等同于通常编程里理解的 IO 依赖。</p>
<p>组合模式，一般就意味着其中必须有一个名词。</p>
<p>数据没有方法。死的和活的应该是截然分开的。</p>
<p>如果我的开源作品大部分的技术细节和架构都能够看懂的话。有些面试官不问技术，有些是精明，有些是含混。还待细究。</p>
<p>[ ] #init , #compute, #result</p>
<p>[ ] 1.Book替代new Book，表示了把创建一个或多个对象放在同一位置上的尊重。</p>
<p>[ ] 有了 |> , 就可以取消 while 和loop了。</p>
<p>[ ] SQL简洁的原因是内省的数据流，而且没有四处引用。</p>
<p>[ ] 编程语言和自然语言的区别是，编程语言是死的，而自然语言是活的，前者依赖于解释器编译器，后者依赖于人类大脑，而人类大脑思维几千几万年不变。</p>
<p>[ ] 上下文没有函数属性，那么就必定强迫使用组合了。</p>
<p>[ ] Shell就是组合模式，加文本管道。</p>
<p>[ ] 其实while和loop是同一个，可以相互表示的。loop是while的超集，只是while把跳出判断放在开始固定位置了而已。</p>
<p>[ ] 计算机并发的本质是逻辑并发，或者曰并行。针对产出而言，所以往往是 IO 并发。至于其他 IO 依赖，传统上也是一个进程搞定。或者像一般服务器架构，分离出队列和处理等，这样其实不需要在语言层面并发。</p>
<p>[ ] 全栈工程师不能说写简单的涉及到全栈就称为全栈工程师了，在我看来，亲自写代码和优化代码的架构师级别才算是全栈工程师。如果对自己的用到的技术做不到了解，那充其量也仅仅只是技术消费者而已。</p>
<p>[ ] 编程语言的问题在比如 hadoop 大的框架里会带来更多的偏见问题。系统太费解。</p>
<p>[ ] 函数上下文的self，this，通过组合式解决。</p>
<p>[ ] 当属性和组合发生冲突？默认属性优先级更高，而且一半静态数据类吧。</p>
<p>[ ] 单例的别扭就是在于类实例化是个别扭的概念。</p>
<p>[ ] 研究Alan Perlis的algol，SICP里序言说的很好。</p>
<p>[ ] 衡量一个编程语言是否更好，就是找不到第二个比它表达这种业务更合适的了。如果标准有歧义，请以人类思维和自然语言为准。</p>
<p>[ ] 1#变量。表示循环层级。</p>
<p>[ ] dirty解决方案取决于是否是相对永久性的，一般我用的是后者。</p>
<p>[ ] 程序是上下文组合，自然语言也是上下文组合，两者区别是前者是死的，和逻辑绑定在一起了，因为上下文只能照固定规则流动。而自然语言却富有千百年的诠释能力。</p>
<p>[ ] 程序开发不是递增的方式，那等于什么也没说，当然是一步一步开发啦。正确的是，程序开发是以上下文的方式开发的，整体是一个上下文，各个细部都是上下文，在每个上下文里思考和编码。</p>
<p>[ ] 函数内部有编号，这样可以动态插入代码。编号是很重要的，可以被增删改查。相当于函数中函数。</p>
<p>[ ] 1#hello, 2#world 也是合法变量名，用于层次化区分.</p>
<p>[ ] 模块化这个术语不错，可是有点苍白，没有揭示模块之间的联系，因此上下文更加合适，把我们所处的问题切分成各个层次的上下文。</p>
<p>[ ] 流来解决并发问题，其实就是排队，统一交给一个人处理，分离读写权限隔离。本来就需要花时间处理，隔离，加锁，这已经是最小代价了。</p>
<p>[ ] 编程语言学多是好事，而不会混乱，这样就只会用各个语言精华的部分。</p>
<p>[ ] 可以获取某对象的折射描绘，比如属性太多就分类一下。可以作为系统函数而实现。</p>
<p>[ ] 太多人喜欢满足于粗糙的解决方案，比如企业级开发的多子系统http通信。业务之间加隔离是不佳的，在模块层次上解耦更有力。</p>
<p>|> 其实也是符号。而且要求左右遵守协议。</p>
<h3>
<a id="情感-哲学-逻辑-艺术-脑科学" class="anchor" href="#%E6%83%85%E6%84%9F-%E5%93%B2%E5%AD%A6-%E9%80%BB%E8%BE%91-%E8%89%BA%E6%9C%AF-%E8%84%91%E7%A7%91%E5%AD%A6" aria-hidden="true"><span class="octicon octicon-link"></span></a>情感, 哲学, 逻辑, 艺术, 脑科学</h3>
<p>情感是一种时间性。比如广告的持续投放对客户的洗脑，时间长了就接受了。而图片认识了就认识了。电影关注故事的意义，看完了就不想看第二遍，音乐没有显示的意义，所以可以买听不厌。经典优化可能也是。唯一是故事不要重复讲，这是最接近大脑思维的，很容易疲倦。</p>
<p>编程是思维的跳跃组织。</p>
<p>男人脱发睾丸酮软件开发。</p>
<p>代码写的像PPT</p>
<p>图灵测试自证的反驳。</p>
<p>发音是语言的回响。声音永远让位于图像。</p>
<p>程序表现是空间性的，而运行却是时间性的，很多人被思维运行方式而把程序写成时间性的了。复制意味着静止和同步，思考和写出的程序都是。</p>
<p>编程就好比教傻子做事，结构化编程非常有益。</p>
<p>mind是创造性的来源，也是毁灭性的来源。</p>
<p>编程是让人的思想在外部执行，当然执行规则得符合外部载体的规则。但是编程也仅仅是人类思维，它根本不是别的什么。人于外部确切沟通的方式只有逻辑？！或者只有逻辑才是确切的。</p>
<p>人们之间相信理由，这个缘由是什么呢？！</p>
<p>同步编程就逻辑而言相比异步更简单（在多个事件之间要显示分离IO顺序），所以大脑会倾向于先忽略同步带来的CPU和IO之间使用率不均衡。</p>
<p>而世界运行的本质呢？可能得求教于物理或者哲学。</p>
<p>你不能根本了解世界和自我的运行本质，而只能经验型的接触。</p>
<p>维特根斯坦《哲学研究》第二页说的“拿5个苹果”在大脑中如何理解这句子里的三个概念“拿”，“5个”，“苹果”。而逻辑只在句子中，不在句子外，所以这三个概念机器理解不了，只能被定义着去模仿。</p>
<p>要求在一个段落里识别“too young to die"。假使 to 的 t 倒着了，因为已经识别了"too young"，概率很高，所以大脑试图纠正 倒着的 to ，以使其满足答案，这样其执行行为就超出了原始需求死板的定义，转而创造性的去发现其中规律，从而达到目的。</p>
<p>从人为什么写作，到为什么必须得编程让计算机接受命令执行。</p>
<p>不只是逻辑，还有美感。</p>
<p>人的思维几千年，几百万年有进化吗？好像没有。</p>
<p>人类说话类似于机器码执行，任何人的表达于TA当时的判断在速度上于TA的能力是最快的，但却可能不是最符合对方的接受执行能力。因此，人又是可以判断对方接受能力或层次，调整自己的表达。 非也。人类可以正交或重复组合各层次概念，以补全对方的理解层次。</p>
<p>维特根斯坦在《哲学研究》序中把札记比作风景画。</p>
<p>人类思维本质在于它是当下的，它是被神秘力量驱动，而自身却不知道。不同人类思维之间只有通过感官沟通进行交流，而本质都是为了维持神秘力量的沟通需求。</p>
<p>具备改变能力的思维生产和消费行为，所以世界是行为主导的，函数式编程把持久化数据弱化为内部状态。</p>
<p>时间是人之间思维得以同步的方式，比如约会，上班。</p>
<p>意识区分出内外。</p>
<p>当面对达芬奇的油画蒙娜丽莎时被要求说出第一感觉，众人按自己审美反馈说神秘，微笑，端庄等，不过数个形容词概念，它们都是一种综合。当面对倾倒出的垃圾桶时被要求说出感觉时，无从规律而言，只反映说混乱。</p>
<p>发散性思维要求对日常经验的思维过程涉及到的概念进行审慎。</p>
<p>医学不可能根治是因为疾病和思维一样，是本质性的，是一种人类无法理解的驱动。中药西药只是从万物关系里调剂而已。所以比如心理问题是本质的，引导为主。</p>
<p>《时间的观念》P168。柏格森。时间意味着创造，意味着对历史的回顾，意味着调整，意味着审美。当代计算机程序的自省依赖于创造人的调整。所以可能还是得归结到自由意志的问题。</p>
<p>现在意味着自我。</p>
<p>目前我对编程本质的体系化可以类比于古希腊哲学的开端。</p>
<p>费曼，总想逃避，这一章，讲了大脑和身体探索。</p>
<p>思维是内在联系的，比如网状的，如果意味着神经细胞消息传递速度，人类体能是类似的。</p>
<p>语言是思维形式。编程语言阻隔日常思维，专业领域，这个事得弄明白。</p>
<p>计算机可不可以实现，意味着可否映射和复制，比如硬件API。情感无法映射，所以替代不了。计算机无法替我们吃饭，做爱，大便。</p>
<p>因果关系意味着简化，来自《逻辑思维》活得明白。判断意味着主体，意味着判断。</p>
<p>梦里用的是另一段记忆区，所以梦里还有以梦。</p>
<p>人的精神本质在DNA里吗？</p>
<p>既然大脑分多个区域，那为什么人基本只能同时想一件事情呢，除非变成躯体运动。</p>
<p>人的理解总是合理的，所以理解存在是好的。</p>
<p>世界不是真这么简单，或简洁，而是一定要在这个领域层次理解的话，定义出来的规则只能这样。如果规则还能解释或预见更多事实的话，它只能说明理论到目前为止还是可靠的（只能在自身理论里自足），但是却无法解释更多理论外的东西，比如相对论介绍不了物理层面之外的事物，如音乐，艺术等。所以人类的本质和未来就是内心而已。</p>
<p>为什么你的个人大脑占据的这部分空间必须可以理解其他所有空间呢，包括与你类似大脑的许多空间。理解是大脑的独特机制。</p>
<p>我的朴素直觉，别人的系统知识，并没有本质区别。</p>
<p>生命和思维之间的关系。狗是如何识别出主人的手，而不将其吃掉，是因为经验和遗传吗。</p>
<p>计算机模仿大脑架构。一切都是源于模仿世界，挖掘意识的背后。</p>
<p>小说的艺术在于呈现什么，古时不带凸显主题组织的流水账。侦探小说在于整体，一个一个抖包袱，包袱包袱相互串联，最后形成整体，真相大白。</p>
<p>解释给别人听，意味着短时记忆，即听觉。但是东西一多，杂乱，就不行了。</p>
<p>在大脑为解密之前，如爱因斯坦说，不可理解的在于它是可以理解的。</p>
<p>美好食物虽然与思想无直接相关，却是思想的养料。</p>
<p>康德哲学难读的短时记忆？</p>
<p>创造是长时和短时记忆的混合。讲故事是长时记忆，可能是。</p>
<p>伟大的作品，就风格来说，必然是个人的，就实用来说，比如是世界的。</p>
<p>性感的Human编程语言。应该是。</p>
<p>短时记忆的创造只有变成长时记忆模式才能被大众接受。</p>
<p>编程更多在于长时思考，所以敲键盘是不需要快的。</p>
<p>长时图形记忆是短期的整合，升级版。</p>
<p>大脑和大脑不能融合，意识不能直接对话。意识的本质，存在，自我，保存，海德格尔的持存。自我真的是个谜。能想象大脑可以融合吗</p>
<p>对我们来说，对大自然进行改造或破坏，对于自我是没有影响的，主体和客体。</p>
<p>说下自己教育背景，退学等。</p>
<p>阅读尼采，仿佛参观一个疯人院。</p>
<p>听音乐的身体颤动共鸣源于音乐的易逝性，生命消逝短暂，死亡恐惧。希特勒演讲。</p>
<p>当自我遇上了自我真是麻烦，遇到他人时因为自我的单CPU性才能保持一个自我。</p>
<p>梦是被四处乱扔的记忆或经历。睡眠时，大脑CPU回到梦区，所以重复梦，或者潜意识最近在想的深刻，渗透到梦区。可以看看睡眠时，大脑哪些区域还活跃着。</p>
<p>计算机的抽象和我们展现了人类的思想可以有多少抽象层次，和物理学等学科有多少类似，但是其根基确实逻辑和二进制，而科学的根基我们却不知。或许计算机的根基是思维本身，而思维的根基就是另外的哲学神学美学问题了。</p>
<p>代码即你的思想，所以没有重复。</p>
<p>口腔溃疡，眼睛，身体累，上班远，明白人生。</p>
<p>晓海，架构师，讲给我一样明白。</p>
<p>human编程语言关键字“what，why，how”？后面加说明字符串？注释自动匹配到最相近的代码，如相同则警告。</p>
<p>内省。statlysis，阳光书屋。</p>
<p>连华适龄数学教育，人思想在睡眠时不一样的，用脑电波对大脑的数学部分进行自动训练，就学会了。</p>
<p>听一般主题演讲，听众觉得很有收获，大部分人是总结了大概和个别句子，专业人士会两方面更多。原因是听觉记忆导致。感染力是听觉的艺术。</p>
<p>可以说出混乱的标准，超过六七个，找不出模式，却找不出美的标准。</p>
<p>过多使用听觉记忆，长时间编程，导致脱发。而设计师不会。</p>
<p>human编程语言版权？</p>
<p>听觉记忆正是上帝模式，所以所有创造性来自于顿悟。图像只是助于理解。但是人不可能随时和换人去达到上帝模式。</p>
<p>音乐，即时记忆，激动。绘画不会。</p>
<p>在ruby聚会，吕神和另一人反对一定是确切的七个，说不应该阻拦。</p>
<p>数学是人类理解里属于看上去简约的一类知识，所以面对数学无穷问题更容易暴露出来，事实上涉及这些都是不可能穷尽该问题的。唯一可做的是和叔本华说的一样，在审美创作中麻痹度过，无法停止的欲望，直到死亡。</p>
<p>turing说，“合理性的证明依赖于人类记忆的有限性”。</p>
<p>中文房间很扯淡，汉语和英语在一定程度上是可等价的，而且背后的思维会去引导和意会两者联结。</p>
<p>《图灵的秘密》330页。约翰卢卡斯说机器容易计算，但是不能运行元数学。元数学没有定义哦，我认为他指的是思维。</p>
<p>形容词可以展现对象的多面性。以及思索的更多可能性，挖掘其内在未知。</p>
<p>细节局部都懂，难懂的是整体直观。</p>
<p>科技的显式力量尤为强大，就像男人力量大过女人。</p>
<p>编程本来是数学优先的，可是在实际做事上还是听觉记忆占优，所以命令式为主流。可是编程大师已经融合函数式＋命令式＋。。。了。</p>
<p>理解就是变成直觉？！ 然而直觉是可以遗忘的。</p>
<p>人脑里的数学计算其实是图形化的直观。还有训练为肌肉记忆。</p>
<p>思考是用短时记忆来处理长时记忆，短时记忆是用来被遗忘的。</p>
<p>数据是用来看的，逻辑是用来理解的。</p>
<p>人类的解释是最迷人的东西！</p>
<p>直指计算机科学和编程的核心问题！</p>